[pooma-dev] [PATCH] Use ln rather than cp for * -> *_APP

[John H. Hall]

Gang:
The idea here was that at the time KCC/SGI CC took a long time (days) 
to compile in Optimized mode. So the trick (recommended to us by KAI) 
was to build a debug version and get the ii_files (later ti_files) 
built and then remove the objects a make a single pass to get the 
optimized object files (which still took a while). But, we wanted to 
keep the Debug version of the executable as well as the optimized 
version, hence the copies. Our scripts referred to a common name for 
the executable and it was either a debug version or an optimized 
version depending on the link. By adding the "_1" in our case we could 
specifically get the debug version, and a "_2" for optimized (user 
selectable for the names). Also, the old version of the make system 
went to great pains to keep the builds in what we called suites so that 
we could simultaneously on our many, many processors, build all the 
versions at once (for our regression tests, up to 64 simultaneous 
builds). This meant we had to even have a different TMPDIR for each 
build to avoid file naming collisions.
John


On Tuesday, January 21, 2003, at 12:46  PM, Tarjei Knapstad wrote:

> On Tue, 2003-01-21 at 17:01, Richard Guenther wrote:
>> On 21 Jan 2003, Tarjei Knapstad wrote:
>>
>>> On Thu, 2003-01-16 at 20:15, Richard Guenther wrote:
>>>> Hi!
>>>>
>>>> The following patch reduces diskspace needed for testsuite compile
>>>> by a factor of two.
>>>>
>>> I had thought of suggesting that, but completely forgot. What is the
>>> reason for having the *_APP files there at all? Grepping?
>>
>> Dont know myself...
>>
>>>> Ok?
>>>>
>>> Almost. I would suggest using soft (symbolic) links instead, i.e. ln 
>>> -sf
>>> instead of ln -f.
>>
>> Thought of this, too, but assuming makefiles from users that delete 
>> either
>> of the variant using symlinks does no longer work for them, using
>> hardlinks does. I'd rather drop the damn thing completely...
>>
> Well, I guess that's a (minor) point. I would vote for dropping it
> completely as I can't see that it makes any sense.
>
>> Anybody still knows why these dups were introduced?
>>
> The only reason I can think of is that there may have been some make
> rule once upon a time that went through every example/benchmark subdir
> and ran the binary with _APP in it's filename, but then what would be
> the point in having a binary without the _APP suffix? Maybe new rules
> were made that didn't need the _APP suffix, but it was kept for
> backwards compatibility, who knows.
>
> Tarjei
> <signature.asc>