ES=" to the offending Makefile.am.
As far as I know, it's not documented and may not even be intended
behavior. But I'll use it as long as it does what I need.
--jtc
--
J.T. Conklin
es will be installed
in order?
Many thanks,
--jtc
--
J.T. Conklin
defined in
the Makefile.am.
flattening non-augmented variable assignments seems like a better
solution to the problem of too long lines.
In the mean time, maybe
foo_SOURCES =
foo_SOURCES += [ long list of sources ]
might just work.
--jtc
--
J.T. Conklin
e Automake
> limitations.
True. Currently MPC doesn't generate 100% perfect Makefile.am files,
so I have made extra effort to make the output as close as I can to
what a human would write, since I end up tweaking the output.
--jtc
--
J.T. Conklin
f *.mpc
files. MPC's automake module has a lot of otherwise unecessary code
to track whether a given automake principal has been output in order
to use "=" or "+=".
All that cruft could be removed if automake interpreted "+=" of a
previously unseen variable as an assignment.
--jtc
--
J.T. Conklin
h CLEANFILES, but I have run the same problem
with other automake variables.
I get around it with something like:
CLEANFILES =
if BUILD_FOO
CLEANFILES += bar quux
endif
Hope this helps,
--jtc
--
J.T. Conklin
at there was a bug which has long been fixed. However, I'm
running automake-1.9.4, which is very recent.
--jtc
--
J.T. Conklin
etter suggestions :-).
While AC_CONFIG_PKGCONFIG_IN() is very appealing, writing a script
that takes similar arguments and generates a *.pc.in file that can
be included in the package isn't that much worse. I think this is
what I'll pursue, since it also has the added benefit of working.
--jtc
--
J.T. Conklin
Stepan Kasal <[EMAIL PROTECTED]> writes:
> On Thu, Dec 30, 2004 at 08:19:41PM -0800, J.T. Conklin wrote:
>> However, if I add foo.pc to AC_CONFIG_FILES, autoconf complains that
>> foo.pc.in does not exist (which it does not). However, if I omit it,
>> foo.pc.in is gener
Sorry to follow-up to myself, but with a little help from autoreconf's
-verbose flag I just figured out that this may be failing in automake,
not autoconf. The underlying problem remains.
--jtc
[EMAIL PROTECTED] (J.T. Conklin) writes:
> Roger Leigh's AC_CONFIG_PKGCONFIG_IN m
conf: failed to run automake: No such file or directory
Any suggestions?
--jtc
--
J.T. Conklin
[EMAIL PROTECTED] (J.T. Conklin) writes:
> I think that explicitly setting installdir to @includedir@/foo, etc.
> in the Makefile.am's will work --- but before I do that I thought I'd
> ask whether there a recommended best practice for this?
I just finished trying this, and i
de_HEADERS = bar.h ...
I would like to install the headers in $(includedir)/foo and
$(includedir)/bar.
I think that explicitly setting installdir to @includedir@/foo, etc.
in the Makefile.am's will work --- but before I do that I thought I'd
ask whether there a recommended best pra
pendencies from *_LIBADD; then
creating a list of graph vertices for each library/dependency; and
finally then doing a topological sort to get the order.
This seems like a general solution to the problem, although knowing
nothing about automake internals I don't know how difficult it would
fails because the
linker can't find "-lBAR" -- probably because the BAR and BAZ
libraries haven't been installed yet.
Is there any way to describe this install dependency in automake? Is
reordering the libraries in the Makefile.am necessary and/or sufficent?
Thanks,
15 matches
Mail list logo
