incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Black <abl...@roguewave.com>
Subject Re: Nightly testing failures on AIX 5.3
Date Thu, 07 Dec 2006 23:29:23 GMT
Martin Sebor wrote:
> Andrew Black wrote:
>> Greetings all.
>>
>> Attached is my first try at splitting out the rpath flags into 
>> directory specific variables, along with the Changelog entry.  The 
>> changes are fairly straight forward, but somewhat repetitive.
> 
> I thought the new variables were going to replace
> LDSOFLAGS, STATIC_LDFLAGS, and SHARED_LDFLAGS but
> I see you retained them. Any particular reason
> why they couldn't be removed?

LDSOFLAGS is used in the compilation of characterization tests which 
involve building a library (these are named ending in .lib.cpp).  I 
suppose it would be possible to use the name LDFLAGS.cfg for this 
purpose, but you would then need a different name for characterization 
tests that involve building an executable.  It also provides a common 
variable so that a user adding a flag to all libraries doesn't have to 
repeat the flag in 3 places.

In a similar vein, the common LDFLAGS variable provides a common 
variable so that a flag needed in all link lines doesn't need to be 
repeated 6+ times.  STATIC_LDFLAGS and SHARED_LDFLAGS provide flags that 
only are needed in archive or shared builds respectively (see 
como.config, eccp.config and reliant_cds.config).  I didn't rename them 
(to either LDFLAGS.archive and LDFLAGS.shared or LDFLAGS.static and 
LDFLAGS.share) as it would be a noise change.

> 
> One note about the naming convention: BUILDMODE
> uses "archive" and "shared" for what you call
> "static" and "share." We should decide on one and
> use it consistently. My personal preference
> between the two is what's already in use.

Changing names for the new variables isn't a difficult task, and using 
archive/shared because those are already in use is as good a reason as 
any for a name.

> Finally, is your plan to apply the same convention
> to the other variables (like CXXFLAGS, etc.) in a
> followup patch?

At this time, I'm not aware of any other flags that vary both by target 
directory and platform, though I could be mistaken.  As such, I'm not 
certain what immediate benefit would be gained by adding them.

For the benefit of the list, Martin and I discussed offline a possible 
rework of the makefile infrastructure.  The idea behind the rework was 
to allow multiple build types within the UNIX build directory.  To do 
this, we'd need to alter the build directory structure so all needed 
Makefile variables would be available and could be combined on the fly.

One proposed structure is to create multiple input makefiles, which 
could be imported, based on build type.  A disadvantage of this tactic 
is potential difficulties in automatically generating the input 
makefiles, as variable names increase.

A second possible structure is to include the appropriate .config file 
in the build directory.  One trade-off of this route is that altering 
the makefile variables could require altering the source .config files 
if non-standard flags are required.  A second trade-off is that some of 
the operations in the .config files are expensive, but I don't know how 
expensive they are, compared with the rest of the process.  This 
trade-off could be mitigated by caching the expensive values, and only 
generating them if needed, but this would require a number of ugly 
additions to the .config files to accommodate this.

--Andrew Black

Mime
View raw message