stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: Nightly testing failures on AIX 5.3
Date Fri, 08 Dec 2006 02:01:03 GMT
Andrew Black wrote:
> 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

We call them configuration 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's important that the library be configured with a set of flags that's
compatible with those it will end up getting built with. We had many
difficult to diagnose problems in the past because of subtle
differences. The best way to guarantee compatibility is to use the same
set of flags, i.e., LDFLAGS.lib.

> 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.

I suppose that would be a reason to keep it. OTOH, we only have two
libraries, stdcxx and rwtest, so I'm not sure keeping the variable
just on the off chance that someone will want to customize their
link lines the same way is worth it. And since we already agreed
to remove it (recall http://tinyurl.com/ymlltq) I think we should
go with the plan.

> 
> 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.

Yes, that's fine. We discussed and agreed to keep LDFLAGS. I also
assumed we'd keep the other variables, CPPFLAGS and CXXFLAGS (in
addition to adding the suffixed forms at some point).

> 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 of the goals of this project is to introduce a consistent and
flexible naming convention for these variables. Keeping names that
follow the old convention while introducing ones for essentially
the same thing that follow the new defeats that goal. That being
said I can see how these variables might be useful. If we are using
them in a way that the new variables cannot easily accommodate let's
rename the, according to the new convention, i.e., STATIC_LDFLAGS to
LDFLAGS.archive and SHARED_LDFLAGS to LDFLAGS.shared. Otherwise,
let's get rid of them and use the new ones instead.

> 
[...]
>> 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.

The immediate benefit would be greater flexibility and consistency with
the newly introduced flags. That was one of the goals of this exercise.

My vision is to have a small set of makefile variables with established
names and well-known meaning (CPPFLAGS, CXXFLAGS, LDFLAGS) and use a
dot suffix (.lib, .test, etc.) to describe which set of projects (and
which major configuration or BUILDMODE, i.e., shared, archive, etc.)
each of them should be applied to.

> 
> 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.

Yes, I think this would be a useful enhancement. The immediate objective
of this project was to make it easier and cleaner to set compiler and
linker flags for each set of components (examples, tests, etc.) This was
precipitated by the observation that we have no way to avoid using the
rpath flag for library builds when we need to using when linking
everything else.

Thanks for the summary!
Martin

> 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.

To be exact, based on the build mode (BUILDMODE). I.e., we might have
config.archive,narrow and config.shared,wide (among others) describing
which flags to use to build all the components in each subdirectory of
BUILDDIR in the corresponding configuration.

> 
> 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.

Some of the operations would be prohibitively expensive when using the
makefiles interactively to build just a single test or example. For
instance, the gcc config file has 11 invocations of the shell function
each followed by a utility. That's 22 processes right there, with the
shell having to read its configuration file(s) from the users home
directory. That can get expensive, especially when working across
the NFS.

Martin

Mime
View raw message