> -----Original Message-----
> From: Tom Tromey [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 14, 2002 10:40 AM
> Rob> While defining a new target to be $(includedir)/foo lets
> you work
> Rob> around this, it would be great to do something like:
> Rob> nobase_preserve_foo_HEADERS = ...
>
> I have some questions about this. What if `foo' appears
> twice in the directory name? What if `foo' doesn't appear?
> Is this the most useful way to handle this feature or is
> there another way? In any case something along these lines
> does make sense. The question (for me anyway) is specifying
> it properly.
Yeah. I fiddled around with various ideas before posting. A different
one was
nobase_include_HEADERS = ...
include_HEADERS_strip = foo/bar/delta
where foo/bar/delta is removed from the path.
> I've been thinking of adding a _NAME macro that would let you
> do this. For instance:
>
> bin_PROGRAMS = my-install
>
> my_install_SOURCES = ...
> my_install_NAME = install
>
> In the build tree we would build `my-install', but at install
> time we would run the _NAME through the program transform and
> then install the program under the resulting name.
As folk do that anyway with --program-transform-name=, a more granular
mechanism should be fairly straightforward. I like it.
> We would do this for programs. It would be nice to do it for
> libraries (it has come up more than once) but it means
> problems if programs are linked against them in the build
> tree. Maybe we could implement it by building the library
> under the real name and having the _NAME name be just a
> stamp-like file.
>
> Any comments on this?
Sounds reasonable. What about this:
For libraries, could you tell automake to use a different name for
whatever builtin is conflicting? i.e. (using install as an example (say
I am building a module called install)).
AM_builtin_install = realinstall
and from there on in, automake uses realinstall instead of install in
all it's targets - including the install (now realinstall) target.
Rob