<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>I believe people typically install to /usr/local/cm3 instead of /usr/local.</div><div>There is a philosophical problem here in terms of setup file system</div><div>layout. /<packages>/package and then symlinks from /usr/local/{bin,lib}</div><div>and removal of a package is just removing its one directory recursively</div><div>and cleaning up any orphaned links vs. files put directly into</div><div>/usr/local/{bin,lib} and data maintained on the side as to which file</div><div>came from which package.</div><div><br></div><div><br></div><div>The first way gives more leeway to install extra stuff but not link</div><div>it into $PATH etc.</div><div><br></div><div><br></div><div>The second way I believe is more common.</div><div>It is easy to put together by make DESTDIR=whatever, tar.gz whatever</div><div>and install is just untar, and uninstall either isn't implemented,</div><div>or the data on the side is the output of tar tf, I guess.</div><div><br></div><div><br></div><div>I put it in /cm3 on my systems and $HOME/cm3 where I don't</div><div>have that access, or $HOME/cm3.<target-short> for filesystems</div><div>shared across targets -- e.g. the opencsw machines share filesystem</div><div>across sparc32, sparc64, x86, amd64.</div><div><br></div><div><br></div><div><br></div><div>But yes, I understand.</div><div><br></div><div><br></div><div>Just because it is called "config", does not make it "config".</div><div>It should be refactored.</div><div>And will there be some expectation that the "binaries" can be</div><div>updated while leaving "config" alone?</div><div><br></div><div><br></div><div> > currently I have to patch make-dist.py to make it not</div><div> > tar/gzip. If the script supported the option, I could avoid that patch.</div><div><br></div><div> </div><div> Send your patches here?</div><div> Or fork on github and send pull requests?</div><div><br></div><div><br></div><div>Another "less-binary" bootstrap option is the C archives.</div><div>It is text files, but they are all generated and hard to read.</div><div>I have to get the C backend back to working. :(</div><div><br></div><div><br></div><div>Since you are going into ports, with an expected install place,</div><div>and are building it yourself, you might want to mess with</div><div>rpath, see here:</div><div><br></div><div><br></div><div><div>jbook2:config-no-install jay$ pwd</div><div>/dev2/cm3/m3-sys/cminstall/src/config-no-install</div></div><div><br></div><div><br></div><div><div>book2:config-no-install jay$ grep rpath *</div><div>ALPHA_OSF: args += [ "-rpath", LIB_USE ]</div><div>FreeBSD.common: & " -Wl,-rpath,\\$ORIGIN"</div><div>FreeBSD.common: & " -Wl,-rpath,\\$ORIGIN/../lib "</div><div>Interix.common: % & " -Wl,-rpath,\\$ORIGIN"</div><div>Interix.common: % & " -Wl,-rpath,\\$ORIGIN/../lib"</div><div>Linux.common: & " -Wl,-rpath,\\$ORIGIN"</div><div>Linux.common: & " -Wl,-rpath,\\$ORIGIN/../lib"</div><div>NetBSD.common:M3_SHARED_LIB_ARG = "-Wl,-rpath-link,"</div><div>OpenBSD.common:% & " -Wl,-rpath,\\$ORIGIN" % no $ORIGIN support up to/including 4.7</div><div>OpenBSD.common:% & " -Wl,-rpath,\\$ORIGIN/../lib" % no $ORIGIN support up to/including 4.7</div><div>OpenBSD.common:SYSTEM_LIBS{"ODBC"} = ["-Wl,-rpath,/usr/local/lib -L/usr/local/lib -liodbc" ]</div><div>OpenBSD.common:SYSTEM_LIBS{"POSTGRES95"} = ["-Wl,-rpath -L/usr/local/lib -lpq"]</div><div>gnuld.common: M3_SHARED_LIB_ARG = "-Wl,-rpath,"</div><div>gnuld.common: GNU_LD_APPEND = " -Wl,-rpath," & INSTALL_ROOT & "/lib " % non-portable</div><div>gnuld.common: M3_SHARED_LIB_ARG = "-Wl,-rpath,"</div></div><div><br></div><div><br></div><div> - Jay</div><div><br></div><br><br><br><br><div>> Date: Wed, 3 Jun 2015 10:36:51 +0200<br>> From: adacore@marino.st<br>> To: jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] It works!<br>> <br>> On 6/3/2015 09:18, Jay K wrote:<br>> > 1) "config"'s user configurability is over-implied imho.<br>> > [snip]<br>> > But also, we target not just Unix.<br>> > Yet we have almost the same directory structure on Unix and Windows.<br>> > The difference is that on Windows we put the .dlls in bin.<br>> <br>> It is possible this was misunderstood.<br>> <br>> It's important to release that cm3 will be installed nominally at<br>> /usr/local/bin. On a normal unix system, there could be over 500<br>> packages all installing there. Things like configuration files (.conf)<br>> are nominally installed at /usr/local/etc/. The config directory is<br>> analogous to these.<br>> <br>> I will do the following in any case:<br>> A) move config from bin to etc/<package>/<br>> B) edit cm3.cfg to point to new location<br>> <br>> All I was suggesting is that the script do this for me. It can still<br>> install at bin/ by default, but it would be nice if it could install<br>> elsewhere too.<br>> <br>> <br>> <br>> > Should we use $HOME/etc or $HOME/config?<br>> <br>> Never.<br>> This does not work for packaging.<br>> E.g. prebuild binary packages that are installed (no building required)<br>> <br>> <br>> <br>> > 2) "example" progs<br>> > Yes. Remember how I said I was lazy and made just one, or rather two,<br>> > package sets? That is what you are seeing here.<br>> > Olaf did put more thought/work into this and the .sh files do build a<br>> > few different distribution sets.<br>> <br>> I am fine with what is built. Remember above that cm3 is installed with<br>> 500 other packages. Any program that is not essential and essentially<br>> there as an example could (and my opinion) should be installed in a<br>> place other than bin/. I don't care if it's installed outside of PATH<br>> because it probably won't be called much and absolute path is fine in<br>> this case.<br>> <br>> > 3) I think so. Look for "www" in config?<br>> > 1-3) yes.<br>> > In particular, are you aware of the<br>> > rpath/origin/relink-upon-make-install/LD_LIBRARY_PATH situation?<br>> <br>> <br>> I just remember that the current cm3 in ports, which is split up like I<br>> suggest, had some broken links because I moved these things around. I<br>> can't remember what is actually broken; I'd have to check again. The<br>> point was you can't just move stuff around without changing links, so<br>> the install script would have to do this if it supported alternative<br>> locations.<br>> <br>> <br>> > 4) <br>> > Just command line parsing in make-dist.py.<br>> <br>> Right, but currently I have to patch make-dist.py to make it not<br>> tar/gzip. If the script supported the option, I could avoid that patch.<br>> <br>> <br>> > 5) yes <br>> > 6) I don't understand.<br>> > min is meant to be:<br>> > 6a) a minimal toolset<br>> > You can write hello world.<br>> > cm3, cm3cg, mklib, config, m3core, libm3<br>> > text, threads<br>> > not a gui <br>> > This is subjective. The "resource" stuff should probably be here.<br>> <br>> <br>> The port is only going to install one distribution, and that will be the<br>> "all". The non-used one is just a waste of building; it will be thrown<br>> away.<br>> <br>> Ports framework repackages and stored in FreeBSD's binary package format.<br>> <br>> > 7) You didn't ask. But I kinda think we should only have environment<br>> > variables<br>> > that start CM3 -- CM3 and start CM3_ actually.<br>> <br>> that sounds logical but as long as they are defined it doesn't really<br>> matter to me.<br>> <br>> <br>> > 8) Another large meta point -- this is all clearly imperfect, usually<br>> > for lack of time or energy, not because we felt it was better this way.<br>> > Though there is the angle I gave -- portability.<br>> > Also, autoconf was probably less well established when most of this was<br>> > written.<br>> > The build/conf world seems still to be somewhat unsettled.<br>> <br>> if a python script is sufficient for port needs, this issue isn't<br>> important to me. So far it seems that it is.<br>> <br>> > 9) I have a larger unimplemented vision -- the system should be<br>> > redistributed as one portable hard to read C or C++ .tar.gz.<br>> > This doesn't work today, because "the frontend does layout" -- we<br>> > essentially have 6 flavors of C:<br>> > We could today make 6 distributions of just C and bootstrap from one of<br>> > them, picking the right one.<br>> > Most 64bit systems can run 32bit, so strike those as bootstrap? But not<br>> > quite, e.g. OpenBSD.<br>> <br>> DragonFly is also 64-bit only.<br>> <br>> > I'd like the option for the frontend to defer layout to the backend, and<br>> > for the C backend to output string expressions involving sizeof(size_t)<br>> > or sizeof(char*).<br>> > And, for win32 vs. posix, I'd like quake to compile both, and to<br>> > generate a Makefile that picks the right one, or a .sh/.cmd.<br>> > Oh, and jmpbuf size is in the generated C. I know how to fix that.<br>> > bootstrap specifically could inflate it to the largest known case, which<br>> > is quite large.<br>> > Or, once we generate C++ for excpetion handling, jmpbuf should go away.<br>> <br>> no comment. :)<br>> <br>> John<br></div> </div></body>
</html>