[M3devel] ROOT

Jay jay.krell at cornell.edu
Thu Jul 2 21:30:22 CEST 2009


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.

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

 

My use of hardlinks is not exactly "trendy".

But I was kinda sorta not breaking the "pkg philosophy".

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.

 

 

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.

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.

 

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

 

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


More information about the M3devel mailing list