[M3devel] ROOT

[Tony Hosking]

PS  I don't see the truncated e-mails when I get them -- must be  
something broken on your end.

On 2 Jul 2009, at 13:14, Jay wrote:

>
> [truncated..]
>
>
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] ROOT
>> Date: Thu, 2 Jul 2009 17:13:05 +0000
>>
>>
>> Btw, I think setting an environment variable that points to the  
>> root of the source tree is a pretty small cost to pay, for almost  
>> anything.
>> ROOT is a bit generic I realize.
>>
>>
>> It is worse to be copying files around, I admit, and I'm doing that  
>> too.
>> Another option is to copy /and/ commit the files, perhaps to  
>> sysutils, since we don't have to work with an old sysutils. This is  
>> the same sort of problem, you'll recall, that plagued making  
>> waitpid users not sleep() on pthreads platforms. There are still  
>> small hacks in place for that -- pretty small now, like, assuming  
>> we are on pthreads and not sleeping, to the detriment of user  
>> threads implementations.
>>
>>
>> CM3_ROOT should work, but that might depend on your config file.
>>
>> I am strongly tempted to have cm3 poke around in the CVS  
>> directories and figure it out itself, as so many builds are run  
>> with .sh code that does roughly that.
>>
>> - Jay
>>
>>
>>
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] ROOT
>>> Date: Thu, 2 Jul 2009 16:55:16 +0000
>>>
>>>
>>> As long as there is a need to work with older m3core, there will  
>>> be hacks..
>>> This stuff provides a significant value.
>>> Before, the runpaths recorded would be a directory per dependent  
>>> shared object -- the directory in the package store. And the  
>>> runpaths were not machine portable -- if you install to a  
>>> different location, which is debatable, maybe everyone should be  
>>> stuck with /usr/local/cm3. OR everyone had to set LD_LIBRARY_PATH.
>>>
>>>
>>> With the hard links, people don't have to set LD_LIBRARY_PATH and  
>>> everyone can pick their own install location.
>>>
>>> As well the temporary staging location for a distribution is not  
>>> recorded in the binaries -- e.g. it wouldn't be /usr/local/cm3,  
>>> but /tmp/something.
>>>
>>>
>>> - 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/7da64fb8/attachment-0002.html>