[M3devel] It works!

[Jay K]

I believe people typically install to /usr/local/cm3 instead of /usr/local.There is a philosophical problem here in terms of setup file systemlayout. /<packages>/package and then symlinks from /usr/local/{bin,lib}and removal of a package is just removing its one directory recursivelyand cleaning up any orphaned links vs. files put directly into/usr/local/{bin,lib} and data maintained on the side as to which filecame from which package.

The first way gives more leeway to install extra stuff but not linkit into $PATH etc.

The second way I believe is more common.It is easy to put together by make DESTDIR=whatever, tar.gz whateverand install is just untar, and uninstall either isn't implemented,or the data on the side is the output of tar tf, I guess.

I put it in /cm3 on my systems and $HOME/cm3 where I don'thave that access, or $HOME/cm3.<target-short> for filesystemsshared across targets -- e.g. the opencsw machines share filesystemacross sparc32, sparc64, x86, amd64.


But yes, I understand.

Just because it is called "config", does not make it "config".It should be refactored.And will there be some expectation that the "binaries" can beupdated while leaving "config" alone?

 > currently I have to patch make-dist.py to make it not > tar/gzip. If the script supported the option, I could avoid that patch.
  Send your patches here? Or fork on github and send pull requests?

Another "less-binary" bootstrap option is the C archives.It is text files, but they are all generated and hard to read.I have to get the C backend back to working. :(

Since you are going into ports, with an expected install place,and are building it yourself, you might want to mess withrpath, see here:

jbook2:config-no-install jay$ pwd/dev2/cm3/m3-sys/cminstall/src/config-no-install

book2:config-no-install jay$ grep rpath *ALPHA_OSF:    args += [ "-rpath", LIB_USE ]FreeBSD.common:                     & " -Wl,-rpath,\\$ORIGIN"FreeBSD.common:                     & " -Wl,-rpath,\\$ORIGIN/../lib "Interix.common:  % & " -Wl,-rpath,\\$ORIGIN"Interix.common:  % & " -Wl,-rpath,\\$ORIGIN/../lib"Linux.common:  & " -Wl,-rpath,\\$ORIGIN"Linux.common:  & " -Wl,-rpath,\\$ORIGIN/../lib"NetBSD.common:M3_SHARED_LIB_ARG = "-Wl,-rpath-link,"OpenBSD.common:% & " -Wl,-rpath,\\$ORIGIN"        % no $ORIGIN support up to/including 4.7OpenBSD.common:% & " -Wl,-rpath,\\$ORIGIN/../lib" % no $ORIGIN support up to/including 4.7OpenBSD.common:SYSTEM_LIBS{"ODBC"} = ["-Wl,-rpath,/usr/local/lib -L/usr/local/lib -liodbc" ]OpenBSD.common:SYSTEM_LIBS{"POSTGRES95"} = ["-Wl,-rpath -L/usr/local/lib -lpq"]gnuld.common:    M3_SHARED_LIB_ARG = "-Wl,-rpath,"gnuld.common:      GNU_LD_APPEND = " -Wl,-rpath," & INSTALL_ROOT & "/lib " % non-portablegnuld.common:  M3_SHARED_LIB_ARG = "-Wl,-rpath,"

 - Jay




> Date: Wed, 3 Jun 2015 10:36:51 +0200
> From: adacore at marino.st
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] It works!
> 
> On 6/3/2015 09:18, Jay K wrote:
> > 1) "config"'s user configurability is over-implied imho.
> > [snip]
> > But also, we target not just Unix.
> > Yet we have almost the same directory structure on Unix and Windows.
> > The difference is that on Windows we put the .dlls in bin.
> 
> It is possible this was misunderstood.
> 
> It's important to release that cm3 will be installed nominally at
> /usr/local/bin.  On a normal unix system, there could be over 500
> packages all installing there.   Things like configuration files (.conf)
> are nominally installed at /usr/local/etc/.  The config directory is
> analogous to these.
> 
> I will do the following in any case:
>  A) move config from bin to etc/<package>/
>  B) edit cm3.cfg to point to new location
> 
> All I was suggesting is that the script do this for me.  It can still
> install at bin/ by default, but it would be nice if it could install
> elsewhere too.
> 
> 
> 
> >  Should we use $HOME/etc or $HOME/config?
> 
> Never.
> This does not work for packaging.
> E.g. prebuild binary packages that are installed (no building required)
> 
> 
> 
> > 2) "example" progs
> > Yes. Remember how I said I was lazy and made just one, or rather two,
> > package sets? That is what you are seeing here.
> > Olaf did put more thought/work into this and the .sh files do build a
> > few different distribution sets.
> 
> I am fine with what is built.  Remember above that cm3 is installed with
> 500 other packages.  Any program that is not essential and essentially
> there as an example could (and my opinion) should be installed in a
> place other than bin/.  I don't care if it's installed outside of PATH
> because it probably won't be called much and absolute path is fine in
> this case.
> 
> > 3) I think so. Look for "www" in config?
> > 1-3) yes.
> > In particular, are you aware of the
> > rpath/origin/relink-upon-make-install/LD_LIBRARY_PATH situation?
> 
> 
> I just remember that the current cm3 in ports, which is split up like I
> suggest, had some broken links because I moved these things around.  I
> can't remember what is actually broken; I'd have to check again.  The
> point was you can't just move stuff around without changing links, so
> the install script would have to do this if it supported alternative
> locations.
> 
> 
> > 4) 
> > Just command line parsing in make-dist.py.
> 
> Right, but currently I have to patch make-dist.py to make it not
> tar/gzip.  If the script supported the option, I could avoid that patch.
> 
> 
> > 5) yes 
> > 6) I don't understand.
> > min is meant to be:
> >  6a) a minimal toolset
> >  You can write hello world.
> >  cm3, cm3cg, mklib, config, m3core, libm3
> >  text, threads
> >  not a gui 
> >  This is subjective. The "resource" stuff should probably be here.
> 
> 
> The port is only going to install one distribution, and that will be the
> "all".  The non-used one is just a waste of building; it will be thrown
> away.
> 
> Ports framework repackages and stored in FreeBSD's binary package format.
> 
> > 7) You didn't ask. But I kinda think we should only have environment
> > variables
> > that start CM3 -- CM3 and start CM3_ actually.
> 
> that sounds logical but as long as they are defined it doesn't really
> matter to me.
> 
> 
> > 8) Another large meta point -- this is all clearly imperfect, usually
> > for lack of time or energy, not because we felt it was better this way.
> > Though there is the angle I gave -- portability.
> > Also, autoconf was probably less well established when most of this was
> > written.
> > The build/conf world seems still to be somewhat unsettled.
> 
> if a python script is sufficient for port needs, this issue isn't
> important to me.  So far it seems that it is.
> 
> > 9) I have a larger unimplemented vision -- the system should be
> > redistributed as one portable hard to read C or C++ .tar.gz.
> > This doesn't work today, because "the frontend does layout" -- we
> > essentially have 6 flavors of C:
> > We could today make 6 distributions of just C and bootstrap from one of
> > them, picking the right one.
> > Most 64bit systems can run 32bit, so strike those as bootstrap? But not
> > quite, e.g. OpenBSD.
> 
> DragonFly is also 64-bit only.
> 
> > I'd like the option for the frontend to defer layout to the backend, and
> > for the C backend to output string expressions involving sizeof(size_t)
> > or sizeof(char*).
> > And, for win32 vs. posix, I'd like quake to compile both, and to
> > generate a Makefile that picks the right one, or a .sh/.cmd.
> > Oh, and jmpbuf size is in the generated C. I know how to fix that.
> > bootstrap specifically could inflate it to the largest known case, which
> > is quite large.
> > Or, once we generate C++ for excpetion handling, jmpbuf should go away.
> 
> no comment. :)
> 
> John
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150603/38aeb86f/attachment-0002.html>