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
