Re: true path

[Steven Knight]

On Fri, 27 Apr 2001 address@hidden wrote:
> I am currently attempting a conversion of my project custom make environment 
> to
> cons. I'm finding that adding a function such as:
>
>      sub cons::truePath {
>          my ($env) = shift;
>          my ($file) = shift;
>          $dir::cwd->lookupfile($env->_subst($file))->path;
>      }
>
> to my Construct is very helpful.

This is a lot like FilePath and DirPath, but takes the environment
and does the substitution.  I can see where that might be useful.

>                                  This is because when linking an executable 
> (via
> cons::Program) I must alter the cons environment so that the appropriate
> libraries are included. Unless I use truePath on them, they end up on the
> command line as specified. Here is an example from a prototype Conscript:
>
>      # Take a copy of the environment to add appropriate LIBS
>      %regressEnv = $CONS->copy();
>
>      for my $lib (@libs) {
>          $regressEnv{LIBS} .= ' ' .
> $CONS->truePath("#server/$lib/${lib}_s%SUFLIB");
>      }
>
>      $regressEnv{LIBS} .= ' ' . $CONS->truePath('sdm%SUFLIB');
>      $regressEnv{LIBS} .= ' ' . $CONS->truePath('#tuxedo/tux_s%SUFLIB');
>      $regressEnv{LIBS} .= " %ATALIBS";
>      $regressEnv = new cons(%regressEnv);
>
>      # build executable linking against the correct LIBS
>      $regressEnv->Program('sdm_regress', 'c/sdm_regress.c');
>
> Does this seem right?
> Is there a way to avoid the use of truePath?
> Is there a different way to build executables that require linking against
> specific libraries?
> Is there a better idiom for using a modified copy of the environment to add a
> build rule (seems like a struggle)?

However, it seems to me that you're making extra work for yourself.
What's wrong with listing the directories that store your libraries in
LIBPATH?  You should then be able to list your libraries using LIBS =>
'-lsdm -ltux_s' and have Cons do the %SUFLIB expansion for you...

Oh, wait, this looks like you're on Windows NT, right?  Rajesh just
hit upon the fact that the -llib idiom doesn't work as you'd expect
there.  There's an undocumented hack for NT that Jochen Schwarze added
a long time ago; if you use the construction variable %_LIBS (note the
underscore) in your LINKCOM command, you can use -llib and have it
expand properly.

We should probably just support -llib expansion in the %LIBS variable on
all platforms by default.  Does anyone have any reason not to?

        --SK