freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John H. Hall
Subject: Re: [pooma-dev] [PATCH] Use ln rather than cp for * -> *_APP
Date: Tue, 21 Jan 2003 15:39:08 -0700

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>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]