automake - libtool - lib.so - lib.a
Hello Using : ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27 11:12:27) Makefile.am : lib_la_LIBADD = /usr/local/lib/lib2.a ./lib.o ... I would like to make a lib.so library with an other static lib2.a library but I have *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. Any idea ?? Thanks a lot François -- [EMAIL PROTECTED] BULL-CITBtel:(+33) 556 437 848 Home: [EMAIL PROTECTED] 207, cours du Médoc fax:(+33) 556 437 978 http://www.citb.bull.net 33000 Bordeaux BullCom: 227 7848 ICQ :3886291 Linux -
Re: Portable, Provable, Path separator test?
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: Tim> I'd like to add (at some point) a macro that detects the path Tim> separator used on the _build_ system. It's fine with me. I'd check a patch implementing it into automake. I don't know the answer to your problems though. Tom
Re: Automake shooting in its foot
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> The patch below gives this on the very CVS Automake package: Akim> * m4/depend.m4 (AM_DEPENDENCIES): Don't leave `AC_PROG_CC' etc. in Akim> clear. Akim> * m4/init.m4: Likewise. Akim> * m4/sanity.m4: s/conftestfile/conftest.file/. Please check this in. Tom
Re: Automake shooting in its foot
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: Tim> However, Emacs Lisp also has 'defadvice' which allows you to Tim> attach arbitrary code to an existing function in different Tim> ways. I must admit that whole advice thing strikes me as a little Tim> insane; it's probably quite powerful though. Advice is very, very useful in some situations. I've used it with Tcl programs I've written to good effect. However, overuse of advice makes for unreadable and unmaintainable code. It should definitely only be used in a small number of situations. I'd guess it would make sense to have some advice-like capability in autoconf. I've certainly wanted it more than once. Tom
Autoconf 2.49c: Release candidate
The following message is a courtesy copy of an article that has been posted to gnu.utils.bug as well. The Autoconf team is extremely proud (and quite relieved) to announce the birth of Autoconf 2.49c, our release candidate. The core Autoconf is not expected to change before the release, while the documentation and minor details still need some work. Since there is a significant number of changes, we would like to ask maintainers to give a try to this version, so that problems be identified before the 2.50 release. Autoconf can be downloaded from ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.49c.tar.gz Happy configuring! Akim, Alexandre, Jim, Pavel, Paul, and Tom. NEWS: * Major changes in Autoconf 2.49c -*- outline -*- ** Lots of bug fixes Way too many for us to spell them out. Check out ChangeLog if you really want to know more. ** Improved documentation In particular portability issues are better covered. ** Use of Automake All the standard GNU Makefile targets are supported. The layout has changed: m4/ holds the m4 extensions Autoconf needs for its configuration, doc/ contains the documentation, and tests/ the test suite. ** Man pages are provided For autoconf, autoreconf, autoupdate, autoheader, autoscan, ifnames, config.guess, config.sub. ** autoconf - --trace Provides a safe and powerful means to trace the macro uses. This provide the parsing layer for tools which need to `study' configure.in. - --warnings Specify what category of warnings should be enabled. - When recursing into subdirectories, try for configure.gnu before configure to adapt for packages not using autoconf on case-insensitive filesystems. - Diagnostics More errors are now caught (circular AC_REQUIRE dependencies, AC_DEFINE in the action part of an AC_CACHE_CHECK, too many pops etc.). In addition, their location and call stack are given. ** autoupdate autoupdate is much more powerful, and is able to provide the glue code which might be needed to move from an old macro to its newer equivalent. You are strongly encouraged to use it both to modernize your `configure.in', but also your .m4 extension files. ** autoheader The internal machinery of autoheader has completely changed. As a result, using an `acconfig.h' should be considered as obsoleted, and you are encouraged to get rid of it using the AH macros. ** autoreconf Deep overhaul. ** Fortran 77 compilers Globally, the support for Fortran 77 is considerably improved. Support for automatically determining a Fortran 77 compilers name-mangling scheme. New CPP macros F77_FUNC and F77_FUNC_ are provided to wrap C/C++ identifiers, thus making it easier and more transparent for C/C++ to call Fortran 77 routines, and Fortran 77 to call C/C++ routines. See the Texinfo documentation for details. ** Test suite The test suite no longer uses DejaGNU. It should be easy to submit test cases in this new frame work. ** configure - --help, --help=long, -hl no longer dumps useless items. - --help=short, -hs lists only specific options. - --help=recursive, -hr displays the help of all the embedded packages. - Remembers environment variables when reconfiguring. The previous scheme to set envvar before running configure was ENV=VAL ./configure what prevented configure from remembering the environment in which it was run, therefore --recheck was run in an inconsistent environment. Now, one should run ./configure ENV=VAR and then --recheck will work properly. Variables declared with AC_ARG_VAR are also preserved. - cross-compilation $build defaults to `config.guess`, $host to $build, and then $target to $host. Cross-compilation is a global status of the package, it no longer depends upon the current language. Cross compilation is enabled iff the user specified `--host'. `configure' now fails if it can't run the executables it compiles, unless cross-compilation is enabled. - Cache file The cache file is disabled by default. The new options `--config-cache', `-C' set the cache to `config.cache'. ** config.status - faster Much faster on most architectures. - concurrent executions It is safe to use `make -j' with config.status. - human interface improved It is possible to invoke ./config.status foobar instead of the former form (still valid) CONFIG_COMMANDS= CONFIG_HEADERS= CONFIG_LINKS= \ CONFIG_FILES=foobar:foo.in:bar.in \ ./config.status The same holds for configuration headers and links. You can instantiate unknown files and headers: ./config.status --header foo.h:foo.h.in --file bar:baz - has a useful --help ** Identity Macros - AC_COPYRIGHT Specify additional copyright information. - AC_INIT Now expects the identity of the package as argument. ** General changes. - Uniform quotation Most macros, if not all, now strictly follow the `one quotation level' rule. This results in a more predictable expansion. - AC_REQUIRE A sly b
RE: Automake shooting in its foot
> Morten> Emacs Lisp comes to mind.. ;-) > > Not exactly: AFAIK, you can't freely hook whatever function: you hook > on existing hooks. Right? Yes the 'hook' concept in Emacs Lisp requires a function to explicitly run those hooks, i.e. hooks are only available if the person writing a routine makes them available. However, Emacs Lisp also has 'defadvice' which allows you to attach arbitrary code to an existing function in different ways. I must admit that whole advice thing strikes me as a little insane; it's probably quite powerful though.
Re: Automake shooting in its foot
> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes: Morten> Akim, >> In fact, I am still against generic hooks because that's a bad >> thing to do. Nobody where ever imagine doing this in another >> programming language. [...] Morten> Emacs Lisp comes to mind.. ;-) Not exactly: AFAIK, you can't freely hook whatever function: you hook on existing hooks. Right?
Re: Automake shooting in its foot
Akim, > In fact, I am still against generic hooks because that's a bad thing > to do. Nobody where ever imagine doing this in another programming > language. [...] Emacs Lisp comes to mind.. ;-) Regards, Morten
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Worst case, we can break AC_DEFUNed macros into two macros, Alexandre> one with the actual name, that contains the prologue and Alexandre> the epilogue and, between them, an invocation of another Alexandre> macro, containing the actual code. Then, hooking something Alexandre> before or after a pro/epi macro would be just a matter of Alexandre> pre/appending the code to this other macro. We absolutely agree: all the solutions which seem sound are expensive. This one being the a priori cleanest _if_ we really want to establish hooks for all the macros in the world. In the case of AC_PROG_CC and the like, I'm no sure that's what we want: given that it comprises several very different steps, I wouldn't be surprised that Libtool and Automake would like to insert themselves at different levels. Not to mention the order between Libtool and Automake hooks themselves. Alexandre> The good thing is that, when they break, people notice it Alexandre> immediately. :) :) :) Very true!
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> In which case, we might attempt to match pro/epi in the
Alexandre> defn and insert the hooks before/after the actual DEFUN,
Alexandre> i.e., between pro and epi.
> Oh, just that? ;)
I have no idea whether it's hard to do.
Worst case, we can break AC_DEFUNed macros into two macros, one with
the actual name, that contains the prologue and the epilogue and,
between them, an invocation of another macro, containing the actual
code. Then, hooking something before or after a pro/epi macro would
be just a matter of pre/appending the code to this other macro.
> I understand the goal was noble and user oriented. But I find it
> extremely dangerous.
Point taken. We have to be careful not to break it. So far, it's
worked moderately well. The good thing is that, when they break,
people notice it immediately.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Only if the macro is AC_DEFUNed. Well, since we're referring to AC_REQUIRE'd macros etc., they are :) Or where you talking about the cost? Then, yes, agreed, only for AC_DEFUN'd macros. ~/src/ace % ace -i -t m4_define:define -t m4_defun:defun In which case, we might attempt to match pro/epi in the Alexandre> defn and insert the hooks before/after the actual DEFUN, Alexandre> i.e., between pro and epi. Oh, just that? ;) >> Finally, let me state things clearly: I'm doing this to help people >> proceed with their bad habits, but from the beginning I was against >> hooking on AC_PROG_CC etc. Alexandre> It was the only way to achieve a design decision in Alexandre> automake (automatic dependency tracking) and libtool Alexandre> (automatic compiler configuration). Sorry you didn't like Alexandre> it. I understand the goal was noble and user oriented. But I find it extremely dangerous. Since these are macros which are probably the most AC_REQUIRE's the pro/epi is extremely important, and I'm sure we don't really envision all the pitfalls around there. Not to mention the hair I had to keep in CVS Autoconf so that it still works today. Alexandre> But unless autoconf supplies clean manners to do what is Alexandre> needed, people (myself included, or should I say especially Alexandre> myself) will find ways around the limitations. I definitely agree. I would certainly not diminish the responsibility of Autoconf in here. Nothing was prepared to that, and nobody is to blame for the current state. I apologize if I gave the impression I was against people: I'm against the code. I'm really hoping to open the compiler checking macros to the needed hooks. Or any other solution. The thing is, someday the Autotools must make tabula rasa and synchronize, and listen to each other. >> In fact, I am still against generic hooks because that's a bad >> thing to do. Nobody where ever imagine doing this in another >> programming language. Alexandre> Except those insane folks that came up with OO, right? :-) Groumph. Well, one point :)
Re: Automake shooting in its foot
The patch below gives this on the very CVS Automake package:
% diff Makefile.in Makefile.in.old
63a64,67
> CC = @CC@
> CPP = @CPP@
> CXX = @CXX@
> CXXCPP = @CXXCPP@
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* m4/depend.m4 (AM_DEPENDENCIES): Don't leave `AC_PROG_CC' etc. in
clear.
* m4/init.m4: Likewise.
* m4/sanity.m4: s/conftestfile/conftest.file/.
Index: Makefile.in
===
RCS file: /cvs/automake/automake/Makefile.in,v
retrieving revision 1.242
diff -u -u -r1.242 Makefile.in
--- Makefile.in 2000/12/23 21:42:43 1.242
+++ Makefile.in 2001/01/24 14:20:18
@@ -61,10 +61,6 @@
AMDEP = @AMDEP@
AMTAR = @AMTAR@
AWK = @AWK@
-CC = @CC@
-CPP = @CPP@
-CXX = @CXX@
-CXXCPP = @CXXCPP@
DEPDIR = @DEPDIR@
MAKEINFO = @MAKEINFO@
PACKAGE = @PACKAGE@
Index: aclocal.m4
===
RCS file: /cvs/automake/automake/aclocal.m4,v
retrieving revision 1.47
diff -u -u -r1.47 aclocal.m4
--- aclocal.m4 2000/12/23 21:42:43 1.47
+++ aclocal.m4 2001/01/24 14:20:22
@@ -15,8 +15,16 @@
# some checks are only needed if your package does certain things.
# But this isn't really a big deal.
-# serial 3
+# serial 6
+
+# There are a few dirty hacks below to avoid letting `AC_PROG_CC' be
+# written in clear, in which case automake, when reading aclocal.m4,
+# will think it sees a *use*, and therefore will trigger all it's
+# C support machinery. Also note that it means that autoscan, seeing
+# CC etc. in the Makefile, will ask for an AC_PROG_CC use...
+
+# We require 2.13 because we rely on SHELL being computed by configure.
AC_PREREQ([2.13])
# AC_PROVIDE_IFELSE(MACRO-NAME, IF-PROVIDED, IF-NOT-PROVIDED)
@@ -36,8 +44,7 @@
# AM_INIT_AUTOMAKE(PACKAGE,VERSION, [NO-DEFINE])
# --
AC_DEFUN([AM_INIT_AUTOMAKE],
-[dnl We require 2.13 because we rely on SHELL being computed by configure.
-AC_REQUIRE([AC_PROG_INSTALL])dnl
+[AC_REQUIRE([AC_PROG_INSTALL])dnl
# test to see if srcdir already configured
if test "`CDPATH=:; cd $srcdir && pwd`" != "`pwd`" &&
test -f $srcdir/config.status; then
@@ -69,38 +76,42 @@
AC_REQUIRE([AC_PROG_MAKE_SET])dnl
AC_REQUIRE([AM_DEP_TRACK])dnl
AC_REQUIRE([AM_SET_DEPDIR])dnl
-AC_PROVIDE_IFELSE([AC_PROG_CC],
+AC_PROVIDE_IFELSE([AC_PROG_][CC],
[AM_DEPENDENCIES(CC)],
- [define([AC_PROG_CC],
- defn([AC_PROG_CC])[AM_DEPENDENCIES(CC)])])dnl
-AC_PROVIDE_IFELSE([AC_PROG_CXX],
+ [define([AC_PROG_][CC],
+ defn([AC_PROG_][CC])[AM_DEPENDENCIES(CC)])])dnl
+AC_PROVIDE_IFELSE([AC_PROG_][CXX],
[AM_DEPENDENCIES(CXX)],
- [define([AC_PROG_CXX],
- defn([AC_PROG_CXX])[AM_DEPENDENCIES(CXX)])])dnl
+ [define([AC_PROG_][CXX],
+ defn([AC_PROG_][CXX])[AM_DEPENDENCIES(CXX)])])dnl
])
#
# Check to make sure that the build environment is sane.
#
+# serial 3
+
+# AM_SANITY_CHECK
+# ---
AC_DEFUN([AM_SANITY_CHECK],
[AC_MSG_CHECKING([whether build environment is sane])
# Just in case
sleep 1
-echo timestamp > conftestfile
+echo timestamp > conftest.file
# Do `set' in a subshell so we don't clobber the current shell's
# arguments. Must try -L first in case configure is actually a
# symlink; some systems play weird games with the mod time of symlinks
# (eg FreeBSD returns the mod time of the symlink's containing
# directory).
if (
- set X `ls -Lt $srcdir/configure conftestfile 2> /dev/null`
- if test "[$]*" = "X"; then
+ set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
+ if test "$[*]" = "X"; then
# -L didn't work.
- set X `ls -t $srcdir/configure conftestfile`
+ set X `ls -t $srcdir/configure conftest.file`
fi
- if test "[$]*" != "X $srcdir/configure conftestfile" \
- && test "[$]*" != "X conftestfile $srcdir/configure"; then
+ if test "$[*]" != "X $srcdir/configure conftest.file" \
+ && test "$[*]" != "X conftest.file $srcdir/configure"; then
# If neither matched, then we have a broken ls. This can happen
# if, for instance, CONFIG_SHELL is bash and it inherits a
@@ -110,7 +121,7 @@
alias in your environment])
fi
- test "[$]2" = conftestfile
+ test "$[2]" = conftest.file
)
then
# Ok.
@@ -122,31 +133,42 @@
rm -f conftest*
AC_MSG_RESULT(yes)])
+
+# serial 2
+
# AM_MISSING_PROG(NAME, PROGRAM)
-AC_DEFUN([AM_MISSING_PROG], [
-AC_REQUIRE([AM_MISSING_HAS_RUN])
+# --
+AC_DEFUN([AM_MISSING_PROG],
+[AC_REQUIRE([AM_MISSING_HAS_RUN])
$1=${$1-"${am_missing_run}$2"}
AC_SUBST($1)])
+
+# AM_MISSING_INSTALL_SH
+# -
# Like AM_MISSING_PROG, but only looks for install-sh.
-# AM_MISSING_INSTALL_SH()
-AC_DEFUN([AM_MISSING_INSTALL_SH], [
-AC_REQUIRE([AM_MISSING_HAS_RUN])
+AC_DE
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
> So to run a hook you need to insert something *inside* the pro/epi
> pair.
Only if the macro is AC_DEFUNed. In which case, we might attempt to
match pro/epi in the defn and insert the hooks before/after the actual
DEFUN, i.e., between pro and epi.
> Finally, let me state things clearly: I'm doing this to help people
> proceed with their bad habits, but from the beginning I was against
> hooking on AC_PROG_CC etc.
It was the only way to achieve a design decision in automake
(automatic dependency tracking) and libtool (automatic compiler
configuration). Sorry you didn't like it. But unless autoconf
supplies clean manners to do what is needed, people (myself included,
or should I say especially myself) will find ways around the
limitations.
> In fact, I am still against generic hooks because that's a bad thing
> to do. Nobody where ever imagine doing this in another programming
> language.
Except those insane folks that came up with OO, right? :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote: >>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> >>> writes: Alexandre> I think it's ok. But I agree the code is messy. We need Alexandre> AC_HOOK(MACRO, BEFORE, AFTER) in autoconf. >> Wow! This sounds real hard, or at least, really expansive if we do >> for all the macros. I was thinking of hooks for AC_PROG_CC and the >> like. Alexandre> Expensive? Alexandre> AC_DEFUN([AC_HOOK],[define([$1], [$2]defn([$1])[$3])]) No, this is why I'm against all the stuff Libtool and Automake are doing: you are forgetting that the core of the macro is wrapped in _epi and _pro. *That*'s the problem. In addition you need at least a dumb check that verifies a hook is not installed after the macro was expanded. I agree it's unlikely, but given the freedom people took with concatenating defn of macros, I'd like to have more sanity checks. So to run a hook you need to insert something *inside* the pro/epi pair. This is pushing some load on every single AC_DEFUN'ed macros. ANd that's where I expect a noticeable impact. This is also why I was thinking of providing the right hooks for AC_PROG_CC etc.: it's efficient, and we can place the hooks at the right place, not before or after. Finally, let me state things clearly: I'm doing this to help people proceed with their bad habits, but from the beginning I was against hooking on AC_PROG_CC etc. There should have been LT_PROG_CC etc. and no macro redefinition games. In fact, I am still against generic hooks because that's a bad thing to do. Nobody where ever imagine doing this in another programming language. Inserting stubs sounds better.
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> I think it's ok. But I agree the code is messy. We need
Alexandre> AC_HOOK(MACRO, BEFORE, AFTER) in autoconf.
> Wow! This sounds real hard, or at least, really expansive if we do
> for all the macros. I was thinking of hooks for AC_PROG_CC and the
> like.
Expensive?
AC_DEFUN([AC_HOOK],[define([$1], [$2]defn([$1])[$3])])
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> I think it's ok. But I agree the code is messy. We need Alexandre> AC_HOOK(MACRO, BEFORE, AFTER) in autoconf. Wow! This sounds real hard, or at least, really expansive if we do for all the macros. I was thinking of hooks for AC_PROG_CC and the like. But your right, the way out is probably more generic than this. But we have plenty of time before :)
Re: More an autopackage
Ganesan Rajagopal wrote: > ... > You normally *have* to package only installed binaries, especially > with libtool libraries. Don't get me started about libtool... :) Actually, now that libtool has pretty much stablized you can just reference the files under the .libs directory, although I've been seriously considering adding a check for this in EPM when it sees an executable (or library) file. -- __ Michael Sweet, Easy Software Products [EMAIL PROTECTED] Printing Software for UNIX http://www.easysw.com
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Meanwhile, can't we just hide the uses of AC_PROG_CC and
Alexandre> _CXX from automake by adding ][ in the middle of their
Alexandre> names?
> Right, but the code is already so hairy that I wondered whether I
> wanted to add more crap into it. If you think it's OK
I think it's ok. But I agree the code is messy. We need
AC_HOOK(MACRO, BEFORE, AFTER) in autoconf.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: PATCH: make install-strip in cross-compilation environments
>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Jan 23, 2001, Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote:
>> INSTALL_STRIP_PROGRAM=$$(topsrc_dir)/$(install_sh) -s
>> and then
>> install-strip:
>> $(MAKE) INSTALL_PROGRAM='$(INSTALL_STRIP_PROGRAM)' install
>> So that $(topsrc_dir) gets evaluated in the sub-make. From
>> the simulation below, it appears to work fine. The question is,
>> is it portable? I mean, will any make perform variable substitution
>> in command line arguments?
Alexandre> I don't think so. But then, you can always use:
Alexandre> INSTALL_STRIP_PROGRAM=`cd $$(top_srcdir) && pwd`/$(install_sh)
Alexandre> $(MAKE) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" install
That wouldn't work for the same reason I said what I suggested
above cannot work: $(install_sh) is not always relative to $(top_srcdir).
IMHO ${install_sh} needs to be expansed at configure time, when
it is defined.
--
Alexandre Duret-Lutz
Re: Automake shooting in its foot
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Meanwhile, can't we just hide the uses of AC_PROG_CC and Alexandre> _CXX from automake by adding ][ in the middle of their Alexandre> names? Right, but the code is already so hairy that I wondered whether I wanted to add more crap into it. If you think it's OK, I'll do.
Re: PATCH: patsubst support
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> Hello! Trying to catch up with the mailing lists :-) Pavel> I'm surprised that this patch has not been applied since Pavel> October. I believe it's very valuable. I even considered doing Pavel> it myself. We ended stuck with a portability problem: it would have let go into Makefile.in nonportable constructs. With a safety belt, it'd been too dangerous for users. We're waiting for a good soul to write the safety net.
