automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: allow convenient library in subdirectory


From: Tom Tromey
Subject: Re: allow convenient library in subdirectory
Date: 16 Jul 2001 22:09:16 -0600

>>>>> "Tim" == Tim Van Holder <address@hidden> writes:

>> +    if ($onelib !~ m%^(?:.*/)?lib[^/]*\.a$%)

Tim> Unless automake slashflips paths, this should probably be
Tim> +  if ($onelib !~ m%^(?:.*[\\/])?lib[^\\/]*\.a$%)
Tim> in order to support DOS paths.

I don't think there's any point in doing this.
I have a few reasons.

First, automake already assumes `/' is the path separator in Makefile.am.
This is scattered all over the code.
As a simple example, see `sub backname'.
There are many more, I'm sure.

Second, automake also generates code that assumes `/' is the path
separator for make.  For instance see lib/am/remake-hdr.am.
There are more of these.

Third, I think dealing with `\' in a Makefile is a pain.
For instance we'll need to quote it for shell commands.

Fourth, suppose we somehow changed automake to be `/'-vs-`\'
agnostic.  Then it seems to me that the generated Makefile.in would
take an even longer time to turn into Makefile (we'd have @..@
explosions even worse than now -- and now it is already bad).  Also
users interested in this sort of portability would have to uglify
their Makefile.am by putting @sep@ all through it.  Eww.
(Substitution speed is a real problem.  One way we might be able to
speed it up would be to change autoconf so that is recognizes automake
conditionals and does faster Makefile processing for them.  We'd have
to do profiling first to be sure though.)

I'd rather we simply declare that we'll only support `/' in Makefile.

Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]