Re: Libraries with sub-libraries....

[Steven Knight]

> I'm using Greg Spencer's Win32 extensions, and the Conscript file for the
> library in question looks like this:
>
> # we want to link another library into this one.  Normally, the AR (unix)
> # command line doesn't include any references to %LIBS (needed to include
> # the libraries), so we'll override it here by defining ARCOM.
> # Aargh.  build::command::library doesn't do the lib path mangling that
> # build::command::link does.  Force resolution by explicitly setting
> ARFLAGS.
        .
        .
        .
> # Double Aargh.  build::command::library doesn't expand library references,
> *either*.

Have you looked at using Module to build the library?  It uses
build::command::link with a specified command (like Command), so you
should be able to get the LIBPATH stuff and the library reference
expansion, without having to redefine a construction variable.  I can't
imagine that, with the right command and construction variables defined,
you couldn't get it to do what you want.

In general, don't get overly misled by the names "Program", "Library",
etc.  They all just munge different sets of construction variables
in different ways to arrive at the command lines needed to build the
target.  For example, you could, if pressed, build a library using
"Program" by redefining construction variables in the right way.  (Not
that that's generally advisable, due to the confusion factor, but...)

So if you need to build a library using things that the
build::command::link builder does, use one of the methods that uses that
builder.  If you're (rightly) concerned about confusing people ("Why are
you using Program to build this library?"), a simple wrapper should do
the trick:

        sub cons::InternalLibrary {
                my($env) = shift;
                $env->Module(@_, "command_to_build_the_library");
        }

        --SK