RE: unable to use $ORIGIN in rpath

[Dave Korn]

On 15 August 2007 19:41, Paul Smith wrote:

> On Wed, 2007-08-15 at 18:02 +0100, Dave Korn wrote:
> 
>> I think I just ran across a similar situation, but I'm not sure it's the
>> exact same.  I define a function in an include file:
> 
> This is a different problem.
> 
>> export if-cpu
> 
> This statement is a no-op.  Shell variable names must match the RE
> [a-zA-Z_][a-zA-Z0-9_]*, so it's illegal for make to export a make
> variable "if-cpu", containing a dash which is an illegal character in a
> shell's variable name, into the environment.  Make will ignore all
> variables that don't have a valid shell variable name when it exports.

  Doh, of course!  I forget how incredibly wide make's variable naming
conventions are compared to - well, compared to pretty much everything else in
the world[*].

  Say, it would probably be a good idea to issue a warning when an export
directive has to be forcibly ignored like that, since it's directly opposite
to the clearly-expressed intent of the makefile programmer.  Would you be
interested in such a patch?

>> Q. - Am I correct in believing that after exporting a variable to the
>> environment, the imported version in a submake will have been through a
>> round of expansion?
> 
> Yes, make will expand recursive variables before exporting them.
> 
>> Q. - Is there any way round this?
>> 
>> Q. - Or is there just no way of defining a function at one makefile level
>> that is any use in recursive submakes if it uses any functions or
>> variables at all? 
> 
> I haven't tested this exhaustively but I'm not prepared to go that far.
> I think it should be possible.  However, one thing that WILL be
> difficult or impossible is having a function that is usable BOTH at the
> top level AND in submakes.

  Ahh, that is of course what I /meant/ to write.  I wanted the top-level
makefile to be able to include the library and then invoke any random submake
without the submake makefile having to know the relative path back to the
library to re-include it.
 
> Again, I'd have to fool around with it for a while to be sure.

  It seems to me to be a fairly big limitation, and not a deliberate (designed
in) one, but a more-or-less chance emergent interaction.

  How about a new kind of export directive that flags a recursive variable to
not be expanded, so that the version that makes it through to the submake has
the *exact* same contents as the version in the top-level make?  Does that
sound like a sensible idea?

    cheers,
      DaveK

[*] - Well, with the possible exception of APL!
-- 
Can't think of a witty .sigline today....