[M3devel] ROOT

[Tony Hosking]

Yes, now I remember.  We need to build a new compiler (from the new  
m3front) in order to compile features (LONGINT) in the new m3core.   
This implies the need for compilations upstream of m3core to function  
with both old and new versions.  So, my question now is why did you  
introduce a dependency from the new cm3 to the new m3core?  That  
should probably be avoided.

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

>
> >> 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/7f6121a4/attachment-0002.html>