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
