[M3devel] ROOT

[Tony Hosking]

On 2 Jul 2009, at 15:30, Jay wrote:

> Btw, I must say, that Modula-3 often bucks the trend, often with  
> reason and benefit.
> However the "trend" has a lot of people behind it, using it, fixing  
> it, making sure it works.
> The "trend", the popular practice, would include put the files in / 
> usr/local/cm3/lib and not pkg.

I am fine with this.

>   Or, well, pkg could be an unused copy, but that's fairly pointless  
> and wasteful.

I don't know what the reasons were for putting them in the pkg  
directories in the first place.

>  My use of hardlinks is not exactly "trendy".
> But I was kinda sorta not breaking the "pkg philosophy".

Does anyone recall if there was any real "philosophy" here?

> It's like the putting an extra unused copy in pkg, but without much  
> space wastage (just directory entries)
>
> At least then the whole symlink/root thing can go away at least.
> Though just using a relative path to get the source file or copying  
> and commiting a smaller piece of it, would be ok..if someone wants  
> hardlink primitive in cm3 for some reason still.

I oppose hard links in general.

>  The runpath won't be huge then also, no matter how all the other  
> debating goes.
>
>
> I need some time to settle down and think about it and /try it out/  
> but at the moment I'm tempted by the ditching of pkg for .so files  
> and just them in lib. It will require probably new builder and  
> config file changes.

RIght.

> Really the current hardlink solution is extremely close to this, but  
> again, also not "trendy".
> .a/.sa files would remain where they are, in pkg, though, of course,  
> there is "very trendy" precedent against that too.

I suspect that the "pkg" philosophy dates from before .so shared  
libraries were even supported on most targets (yes, I can remember  
that long ago).

>  And then, er...what is left in pkg?

Sources.  For browsing by the various Modula-3 tools.  Come to think  
of it, that reminds me -- the package browsing tools (eg, m3browser)  
rely on the .M3EXPORTS and .M3WEB files in the pkg directories.  So,  
this argues for only moving the .so files to INSTALL_ROOT/lib and  
leaving the rest (*.a, *.m3x, .M3EXPORTS, .M3WEB, and derived sources  
in the pkg/TARGET directories where they currently reside).

>
>  - Jay
>
> From: jay.krell at cornell.edu
> To: jay.krell at cornell.edu; hosking at cs.purdue.edu;  
> m3devel at elegosoft.com
> Date: Thu, 2 Jul 2009 19:23:55 +0000
> Subject: Re: [M3devel] ROOT
>
>
> >> But why would you compile a new cm3 with an old m3core?
>
> That is what the "release" builds do on the Tinderbox.
>   If you can fix that, please do. :)
> Notice how I broke them the other day?
> But not the "last ok" build?
>
> They start with a 5.4 compiler.
>  They do NOT build m3core, libm3.
>  Not sure about m3cc.
>  They start with sysutils, then, in whatever order,
>    m3quake, m3middle, m3front, m3back, cm3.
>  Then they use that new cm3 to build
>    m3cc if not done already
>   (clean)
>    m3core, libm3, sysutils, m3front/quake/back/middle, cm3.
>
> At some point, you know, cm3 could not build m3core, when
> cm3 didn't know about LONGINT and m3core used it.
> I don't know if 5.4 is such a version.
>
>
>  > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH?
>
> That's not the entire story.
> If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then
>   - you end up with a huge presumably inefficient runpath
>    This can be addressed by using /usr/local/cm3/lib instead.
>
>   - you end up with insecure /tmp for distribution builds
>   This can be addressed by using $origin or changing how  
> distribution builds are done.
>
>  - You can't "easily" move the install. Though there are utilities  
> in various OSes to edit the paths later, or you can relink upon  
> install. I didn't make that strategy up.
>
>   > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries  
> someplace other than the rpath used in their linkage?
>
> I don't understand. Right, if you want to move stuff around,  
> LD_LIBRARY_PATH is one solution. $origin is another. They aren't  
> equivalent and they have various pluses/minus. Searching the web  
> definitely leads me to favor $origin.
> "The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not  
> scoped to a particular executable, unless you use wrapper scripts. / 
> etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke  
> my own use of my $HOME/cm3/bin, because those binaries are supposed  
> to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH,  
> again, unless you write wrapper scripts.
>
> If we force everyone to install to /usr/local/cm3 or /opt/cm3, the  
> issue is reduced, granted
>
>
> - Jay
>
>
>
> ________________________________
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] ROOT
> Date: Thu, 2 Jul 2009 12:40:18 -0400
>
> I'm not talking about m3overrides. That is a arguably a special- 
> purpose hack. We shouldn't layer a hack into the *normal* build  
> process.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue  
> University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 2 Jul 2009, at 12:19, Jay wrote:
>
>
> Seems broken to me to depend on
> the source directory structure
>
> Like m3overrides? But yes, I agree.
> m3overrides seems broken too.
>
> - Jay
>
>
>
>
>
>
>
>
> ----------------------------------------
> From: hosking at cs.purdue.edu
> To: m3devel at elegosoft.com
> Date: Thu, 2 Jul 2009 11:49:34 -0400
> Subject: [M3devel] ROOT
>
> Where did variable ROOT come from? Do I really need to define it?
> Seems broken to me to depend on the source directory structure as it
> sets that structure in stone.
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090702/5fe3724f/attachment-0002.html>