.
Yes, there is some duplication here. That's why Automake is
droping its arguments and instead try to get these pieces of
information from Autoconf.
[...]
--
Alexandre Duret-Lutz
TOMAKE syntax, which
Ralf> prevented this issue to show, even if using autoconf >= 2.50.
Aside: some people use
AM_INIT_AUTOMAKE([AC_PACKAGE_TARNAME], [AC_PACKAGE_VERSION])
(this won't work with Automake in --gnits mode, though)
[...]
--
Alexandre Duret-Lutz
; external sources [1].
Ralf> * import one or more of these defines from other packages' headers.
This is really an Autoconf issue: that's AC_INIT which defines
these symbols since 2.52g (prior versions don't do this).
Automake's no-define applies only to the symbols that
mp;sfgr;> but then automake fails with:
&Agr;&lgr;&eacgr;&xgr;&agr;&ngr;&dgr;&rgr;&ogr;&sfgr;> src/Makefile.am:8: invalid variable `nobase_include_HEADERS'
&Agr;&lgr;&eacgr;&xgr;&agr;&ngr;&dgr;&rgr;&ogr;&sfgr;> Any pointers anyone?
This should work in the last pre-release, Automake 1.5d.
ftp://sources.redhat.com/pub/automake/automake-1.5d.tar.gz
Could you try it?
--
Alexandre Duret-Lutz
platter> [jks@saba newsmdi]$ gcc -g -lsmdi -o test firsttest.c
platter> /usr/local/lib/libsmdi.so: undefined reference to `pthread_create'
platter> collect2: ld returned 1 exit status
Does the following works?
libtool gcc -g -o test firsttest.c /usr/local/lib/libsmdi.la
[...]
--
Alexandre Duret-Lutz
amp;rgr;&ogr;&sfgr;> I changed AM_PROG_LIBTOOL -> AC_PROG_LIBTOOL and
&Agr;&lgr;&eacgr;&xgr;&agr;&ngr;&dgr;&rgr;&ogr;&sfgr;> aclocal runs fine but then:
&Agr;&lgr;&eacgr;&xgr;&agr;&ngr;&dgr;&rgr;&ogr;&
a workaround?
This is a known problem in Automake. You can use the following
instead:
if SOME_CONDITION
MUMBLE = b
endif
DUMMY = a $(MUMBLE)
--
Alexandre Duret-Lutz
disadvantage that it
Thomas> prefers our supplied m4's, while it would be better to
Thomas> prefer system-installed m4 macros.
aclocal will prefer the local m4/ macros over the system macros
too. I fail to see why this is bad, but if it annoys you it's
easy to order the -I options to that effect:
aclocal -I `aclocal --print-ac-dir` -I m4
[...]
--
Alexandre Duret-Lutz
n it tells you that \r\n -> \n conversion is
performed transparantly on i/o, and that you should use chomp()
instead of chop() to trim newlines because they might take
several characters...
[...]
--
Alexandre Duret-Lutz
hare/aclocal directory twice.
This warning was disabled two years ago :)
[...]
--
Alexandre Duret-Lutz
lation on output (because you removed binmode).
However I fail to see where the original \r\n comes from.
--
Alexandre Duret-Lutz
#
+## Getline
+##
+
+# Some Win32/perl installations fail to translate \r\n to \n on input
+# so we do that here.
+sub getline
+{
+local $_ = $_[0]->SUPER::getline;
+# Perform a _global_ replacement: $_ may can contains many lines
+# in slurp mode ($/ = undef).
+s/\015\012/\n/gs if defined $_;
+return $_;
}
1;
--
Alexandre Duret-Lutz
of 1.6) here:
http://sources.redhat.com/automake/
I suggest you use 1.5d, it fixes many bugs introduced in 1.5.
--
Alexandre Duret-Lutz
as well as
> "/etc/package", how would I be specifying the targets?
pkgsysconfdir = $(sysconfdir)/$(PACKAGE)
dist_pkgsysconf_DATA = package.conf.sample
initsysconfdir = $(sysconfdir)/init.d
dist_initsysconf_DATA = package.conf.sample2
[...]
--
Alexandre Duret-Lutz
>>> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes:
[...]
Patrick> Hints on where to delve/how to fix?
Yep: could you run the same test with VERBOSE=x?
i.e.
gmake check TESTS=make.test VERBOSE=x
--
Alexandre Duret-Lutz
n the
relevant *_SOURCES variable of your Makefile.am.
If rpl.c must be generated from some other files, list it in a
*_SOURCES variable too (or maybe a nodist_*_SOURCES variable)
and add a custom rule to build it.
--
Alexandre Duret-Lutz
rc/local/automake/tests/testSubDir/Makefile
?
[...]
--
Alexandre Duret-Lutz
>>> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes:
Patrick> On Wed, Feb 13, 2002 at 06:54:07PM +0100, Alexandre Duret-Lutz wrote:
>>
Patrick> config.status: creating Makefile
Patrick> + fgrep am__include = # Makefile
Patrick> FAIL: mak
s, and the
Eric> generated Makefile.in is a binary match to the one already in CVS. Go
Eric> ahead and apply this patch before releasing version 1.6, and thanks for
Eric> your help.
Could you run the testsuite, while you are at it?
--
Alexandre Duret-Lutz
which changes.).
You could add this to your Makefile:
.PHONY : rpl.c
[...]
--
Alexandre Duret-Lutz
so if you remove the loop
or the variable assignment. So that's definitely looks like bug
in NetBSD's sh.
Could you take care of reporting this bug wherever appropriate?
(I'm not a NetBSD user myself, and the sh man page doesn't show
any bug-report address.)
--
Alexandre Duret-Lutz
s? I've tried to make a test case which
use the following Makefile.am
AUTOMAKE_OPTIONS = subdir-objects
bin_PROGRAMS = foo
foo_SOURCES = foo/parse.y
but this raised another problem: the specific rule output to
build foo/parse.c does not supports VPATH builds.
[...]
--
Alexandre Duret-Lutz
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> Hi,
>>> "Magnus" == Magnus Fromreide <[EMAIL PROTECTED]> writes:
Magnus> In the rules from lex.am and yacc.am, if the item %OBJ%
Magnus> or the variable LEX_OUTPUT_R
y forgot to run aclocal before autoconf.
[...]
--
Alexandre Duret-Lutz
On Sun, Feb 17, 2002 at 08:35:31PM +0100, Jim Meyering wrote:
>
> * m4/depout.m4: Don't use `head -1'; it's no longer portable.
> Use `sed 1q' instead.
>
Hi Jim! Could you adjust tests/cond12.test and
tests/insthook.test similarly?
Thanks,
--
Alexandre Duret-Lutz
.h)
empty.cpp:
touch empty.cpp
The empty.cpp file is to workaround 1), and the _LIBADD
definition is for 2).
A better setup, as far portability and Automake are concerned,
would be to expand manually all those $(wildcard) in your
Makefile.am (or have a script that generate your Makefile.am).
[...]
--
Alexandre Duret-Lutz
else). Is there a simple way of achieving this?
I can't think of any. Why do you need this?
--
Alexandre Duret-Lutz
>>> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
[...]
Jim> Any objections?
No, please apply.
(Too bad AC_LIBSOURCE cannot be used in this case.)
Jim> 2002-03-05 Jim Meyering <[EMAIL PROTECTED]>
Jim> * automake.in (@common_files): Add config.rpath.
[...]
--
Alexandre Duret-Lutz
e sooner 1.6 can replace 1.5, the better. I can't see any
important bug left over (expect for PR/294)
Tom> I'm in favor of a release and I've been hoping to find the time to do
Tom> one. For me that doesn't look likely in the near future :-(
Come on... don't let Automake 1.6 be beaten by Autoconf 2.53!
--
Alexandre Duret-Lutz
s: upgrade to Automake 1.5 or 1.6. Dependencies are no
longuer included today.
(See http://sources.redhat.com/automake/dependencies.html for
more discussion about Dependency Tracking in Automake.)
[...]
--
Alexandre Duret-Lutz
check VERBOSE=x TESTS='pr300-lib.test pr300-ltlib.test pr300-prog.test'
as well as additional information about your environment (OS, shell, etc.).
[...]
--
Alexandre Duret-Lutz
Index: ChangeLog
===
RCS file: /cvs/automake/automake/ChangeLog,v
retrieving revision 1.1778
diff -u -r1.1778 ChangeLog
--- ChangeLog 2002/03/06 06:47:44 1.1778
+++ ChangeLog 2002/03/07 12:18:11
@@ -1,3 +1,9 @@
+2002-03-07 Alex
27;t! /usr/local/aclocal and /usr/share/aclocal-1.6 are
both read by aclocal, and have different purposes. (One is for
public macros, the other for private macros.)
--
Alexandre Duret-Lutz
for instance those
at the end of
http://mail.gnu.org/pipermail/automake-patches/2002-January/000599.html.
--
Alexandre Duret-Lutz
ed.
Akim> It simplifies the code, addresses your issue, and also guarantees that
Akim> in the future, all such targets will behave as you suggest.
Akim> Would you contribute the AC_PROG_INSTALL macro and install-sh updates?
AFAICT install-sh already does this. This is why we use it to
install nobase_ files.
--
Alexandre Duret-Lutz
d the 'make install`remove
Jens> all files belonging to a older version of aclocal,
Jens> otherwise you may get an unexpected behaviour due to
Jens> double defined macros.
That's not needed. The macros from aclocal-1.6/* are prefered
over those from aclocal/*.
--
Alexandre Duret-Lutz
$(DESTDIR)$(includedir)/$$i; \
done
OSF/Tru64 make creates prerequisite directories magically
When a prerequisite is a sub-directory of `VPATH', Tru64 Make
will create it in the current directory.
% cat Makefile
VPATH = ..
all : foo/bar
% make -p foo/bar build
% cd build
% make
mkdir foo
mkdir foo/bar
This can yield unexpected results if a rule uses a manual
`VPATH' search as presented before.
VPATH = ..
all : foo/bar
command `test -d foo/bar || echo ../`foo/bar
The above `command' will be run on the empty `foo/bar'
directory created in the current directory.
--
Alexandre Duret-Lutz
ce/missing --run
Bernd> whereas with bash2 the automake-1.5d appears correctly after --run.
Thanks for the report. This is already fixed in CVS Automake.
Hopefully it should not take too long before Automake 1.6.1 is
released.
[...]
--
Alexandre Duret-Lutz
oo.c foo.h
foo_LDADD = -Lpathto -lyours
but this second form won't handle dependencies (in case
pathto/libyours.so is built in the same project) automatically.
(All of this remains true for any kind of libraries, e.g. static
libraries or libtool libraries.)
HTH,
--
Alexandre Duret-Lutz
ependent, that's why libtool exits.
Besides, the _LIBRARIES primary supports only static libraries
for now.
Since you don't want to use libtool, remove this lib_LIBRARIES
definition and write your own rule to build libSomeLib.so on
your system.
[...]
--
Alexandre Duret-Lutz
" after "install", because the
former may have installed the library read-only (when given
appropriate flags, which doesn't appear to be the case here).
[...]
--
Alexandre Duret-Lutz
t the info pages don't seem to have such a section.
Robert> Where is this documented? (And what should I change).
Autoconf 2.53 prints this.
It's documented in the Autoconf 2.53 manual.
--
Alexandre Duret-Lutz
aside. Libtool runs these commands; but this is not our
problem.
After the test has failed, can you show us the ouput of
ls -Rl /tmp/automake-1.6/tests/testSubDir/inst/lib
and
strip -v --strip-debug /tmp/automake-1.6/tests/testSubDir/inst/lib/liba.a
--
Alexandre Duret-Lutz
; + exit 1
Dave> FAIL: confsub.test
I can't see any change between Automake 1.6 and CVS Automake
that could have caused this.
However, ISTR that time-stamps have only a 2sec precision on
some Windows file system. That could explain why this test
sometime fails, and sometime doesn't. Does this make sense?
Could you edit confsub.test, change 'sleep 1' to 'sleep 2', and
see if it still fails?
--
Alexandre Duret-Lutz
files for a given
directory by running
% rm -Rf kernel/framework/.deps
% ./config.status kernel/framework/Makefile depfiles
If this fails to create the files in one setup and succeed in
the other, then you could rerun this with `sh -x' and compare
the trace for both cases.
Ah, last question: what sed version are you using? (Just to
make sure it's not the same problem as
http://sources.redhat.com/ml/bug-automake/2001/msg00584.html)
--
Alexandre Duret-Lutz
.deps directories are created.
Is this a build with that macro disabled?
[...]
>> % rm -Rf kernel/framework/.deps
>> % ./config.status kernel/framework/Makefile depfiles
> On my system, this does absolutely nothing.
Please, send the output of
% ./config.status --help
and
% rm -Rf kernel/framework/.deps
% sh -x ./config.status kernel/framework/Makefile depfiles
[...]
--
Alexandre Duret-Lutz
^/][^/]*\/*$/{ s//\1/; q; }
| /^X\(\/\/\)[^/].*/{ s//\1/; q; }
| /^X\(\/\/\)$/{ s//\1/; q; }
| /^X\(\/\).*/{ s//\1/; q; }
| s/.*/./; q'`
| else
|continue
| fi
I guess it could fails for other reasons, like not having fgrep
installed.
[...]
--
Alexandre Duret-Lutz
words like `Automake' and
`wildcard' it will point you to several discussions in the list
archive about pros, cons, and workarounds. Sorry for not being
more precise.
[...]
--
Alexandre Duret-Lutz
#x27;s now AM_CONFIG_HEADER and always ends up being blank, save a
Sean> line saying it's generated by autoheader
Ah yeah, it should probably read "this file was nuked by
autoheader" . Anyway, that's odd: autoheader should not
touch config.h (only config.h.in or any other name you gave it).
Can you give more details?
--
Alexandre Duret-Lutz
ally I thought it was enough
to link against librpl.la -- read .la, not .a -- to get all
the dependencies automatically.)
--
Alexandre Duret-Lutz
it to alf.lo, and this might overwrite
an existing alf.o built for libalf.a.
(Tom will correct this statement when he find some time to read
the list .)
As a workaround, if you add
libalf_a_CFLAGS = $(AM_CFLAGS)
to your Makefile.am, it will cause the libalf.a objects to be
named differently, and they won't conflict with those from
libalf.la.
--
Alexandre Duret-Lutz
some timestamp wrong when making a
tarball manually (I'm assuming that's what you did).
--
Alexandre Duret-Lutz
file additions and file
changes. Do you mean there would be rules to evaluate the
wildcards (i.e. run automake) each time a file changes?
--
Alexandre Duret-Lutz
We're pleased to announce the release of Automake 1.6.1.
This is a bug fix release, and as such there is no new
features since Automake 1.6. The NEWS entry is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.6.1.tar.gz
ftp://ftp.gnu.org/gnu/automake
able static
or shared libraries using --disable-static or --disable-shared),
It seems to me this is what you try to avoid.
Or keep the definition for both libraries, and try the
workaround I mentioned:
libalf_a_CFLAGS = $(AM_CFLAGS)
My limitied testing shows this is enough to suppress the warning.
--
Alexandre Duret-Lutz
ant to
Chadwick> include it in my configure.am and modify my bootstrap
Chadwick> script to specify '--enable-maintainer-mode'?
What are the problems you want to hide with AM_MAINTAINER_MODE?
Maybe we can help you to fix them.
[...]
--
Alexandre Duret-Lutz
anged some source, you need the right tool to
rebuilt it (and obviously you want the maintainer rules too).
If however you touched nothing, you don't care about which
versions you have.
--
Alexandre Duret-Lutz
./configure --prefix=''
$MAKE DESTDIR=$PWD/=inst install
test -f ./=inst/man/man2/foo.2
--
Alexandre Duret-Lutz
27;:
-d Use the file's modification time as the time of import.
This sounds like a good candidate for my .cvsrc :)
--
Alexandre Duret-Lutz
ules are amongst them; so, somehow, it makes sense
that you clean the PDF and HTML at the same time.)
[...]
--
Alexandre Duret-Lutz
onf --version
>> autoconf (GNU Autoconf) 2.52g
Bruce> Is this anything close to the currently recommended set
Bruce> of "tools designed to give you the least hassle"?
I think upgrading to Autoconf 2.53 and Automake 1.6.1 should
only give you bugfixes. (Without hassle since you're already
close to these versions.)
[...]
--
Alexandre Duret-Lutz
Can you try Automake 1.6.1? It should clean subdir libtool objects correctly.
--
Alexandre Duret-Lutz
all-data-local: install-man3
(When an install-data-local rule exists it is automatically
added to the prerequisites of install-data-am, which itself is
required by ... etc., etc., ... required by `install'.)
This doesn't answer your general question, however.
[...]
--
Alexandre Duret-Lutz
e foo/bar/delta is removed from the path.
As a generalization of this and Tom's _NAME, what about:
nobase_include_HEADERS = ...
nobase_include_HEADERS_TRANSFORM = s,^foo/bar/delta/,,
This would be supported for programs and librararies too.
[...]
--
Alexandre Duret-Lutz
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
[...]
Harlan> However, I haven't found a way (in the docs) to tell
Harlan> automake-1.5 the name of this new configure.XX file.
Harlan> How does one do this?
You can't, I'm afraid. Do you need this?
--
Alexandre Duret-Lutz
; is not portable.
Recent Autoconf versions will set or unset CDPATH as
appropriate, so the above line has been rewritten as
am_aux_dir=`cd $ac_aux_dir && pwd`
In Makefiles, however, you still have to fiddle with CDPATH.
Automake 1.6 uses
CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd somewhere && pwd
--
Alexandre Duret-Lutz
g commands can fix the problem.
mv dickey dickey.old
sed 's/sarcasms/useful bug reports/' dickey
chmod +x dickey
PS: Come on... AC_OUTPUT creates config.status! Who want to
call this twice? Besides it is clearly stated "Call this once"
in the Autoconf 2.13 doc.
--
Alexandre Duret-Lutz
cal.m4; or you have an aclocal.m4 but it was generated by an
older version of aclocal. In all cases, please run aclocal
before running automake.
The diagnostic should be clearer if you upgrade to Automake 1.6
or greater.
--
Alexandre Duret-Lutz
fmodule_la_LDFLAGS = -module
This will have the unfortunate side-effect of installing a
couple of other files in addition to alfmodule.so (you can
remove them using an `install-exec-hook').
--
Alexandre Duret-Lutz
...
Joerg> ./configure: AM_PROG_LEX: command not found
Joerg> I assume I have to include something.(?)
Please run aclocal before running automake. Do this each time
you have updated configure.in. (Or read about a tool named
`autoreconf', shipped with Autoconf.)
--
Alexandre Duret-Lutz
ch
has been fixed in 1.6.1. This should be
AUTOMAKE_OPTIONS = dist-bzip2 subdir-objects 1.5
(i.e. without the `VERSION=')
[...]
--
Alexandre Duret-Lutz
>>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> When did it get fixed?
1.6.1
--
Alexandre Duret-Lutz
simply remove the `VERSION='
prefix it will work as you intend (and as documented) with *all*
versions of Automake.
--
Alexandre Duret-Lutz
mf | fgrep 'generated by automake') > /dev/null 2>&1; then
to something like
if (sed 15q $mf | fgrep 'generated by automake') > /dev/null 2>&1; then
or even
if grep '^#.*generated by automake' $mf > /dev/null 2>&1; then
--
Alexandre Duret-Lutz
>>> "Joerg" == Joerg Anders <[EMAIL PROTECTED]> writes:
[...]
Joerg> But what do you recommend to do?
Just relax and wait for the next Automake release :)
--
Alexandre Duret-Lutz
on't know.)
[...]
Joerg> + +if ( !( $MakefileData =~ s/^(.*generated automatically by
automake.*\n)/$1$progIdLine/ ) ) {
hence I suggest something like /^(.*generated .*by automake.*\n)/
[...]
--
Alexandre Duret-Lutz
ate (versioned) and public
(unversioned) aclocal directories, hence the failure. (This
switch is needed in Automake's testsuite which has to run
aclocal before the macros are installed.)
[...]
--
Alexandre Duret-Lutz
s' option.
What do you mean by "to do"? Are you overriding the link rule?
Why these quotes around "gcc -nostartfiles"?
One usually adds link flags such as -nostartfiles using _LDFLAGS
(search maude_LDFLAGS in the Automake manual).
[...]
--
Alexandre Duret-Lutz
ot found in library
Skip> Line 50 is indeed the place where AM_CHECK_PYTHON_HEADERS
Skip> is called, but it is defined starting on line 26 as
aclocal does not search configure.in for macro definitions.
Create a file named acinclude.m4, and move your macros
definitions from configure.in to this file.
[...]
--
Alexandre Duret-Lutz
ck> but libtool ignore it when really performing the link:
Try this:
libfc_la_LDFLAGS = -Xlinker -nostartfiles
--
Alexandre Duret-Lutz
l vanish with the next major
release of Automake, since it will rely on "autoconf --trace" to
parse configure.in. (You can try it, it's in CVS HEAD.)
--
Alexandre Duret-Lutz
gt; is changed, the code should be recompiled, since it will
David> alter the image displayed. However, if I put it as a
David> file along with my sources in
David> atlc_SOURCES atlc.cpp coax.xpm
Missing `='.
David> the compiler will reject it, since it does not know the ex
Is my English that bad? :)
I was merely asking you whether you tried the example you
posted:
altc_SOURCES = atlcFrm.cpp altc.xpm
i.e., listing all sources files in _SOURCES.
--
Alexandre Duret-Lutz
>>> "Yannick" == Yannick Perret <[EMAIL PROTECTED]> writes:
Yannick> Alexandre Duret-Lutz wrote:
[...]
adl> Try this:
adl> libfc_la_LDFLAGS = -Xlinker -nostartfiles
Yannick> I added it, and it change nothing. The _LDFLAGS is
Yannick> transmit
?
The tool you used to carry your files (here, CVS) messed their
timestamps. Use `make dist' if you need something more accurate.
[...]
--
Alexandre Duret-Lutz
this leaves the Libtool issue.
Also, this AM_INSTALL_STRIP_FLAG variable will be set for the
whole project, which doesn't sound terribly useful to me. I'm
pretty sure people will soon ask for per-target strip flags (or
at least per-primary flags).
--
Alexandre Duret-Lutz
7;t this be rewritten as follows?
| .SUFFIXES: _stub.c _skel.c _stub.h _skel.h .idl
|
| .idl_stub.c:
| $(idl) $<
|
| _stub.c_stub.h:
| @:
|
| _stub.c_skel.c:
| @:
|
| _stub.c_skel.h:
| @:
--
Alexandre Duret-Lutz
usually compile with `-Werror', this way I
can never miss a warning and they are easy to locate (always in
the last lines).
[...]
--
Alexandre Duret-Lutz
L' not found in library
Most likely you don't have Libtool installed.
--
Alexandre Duret-Lutz
es-matter issue:
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01692.html
Harlan> Any ideas on how to fix the problem?
Define your rules only once all involved variables are defined?
--
Alexandre Duret-Lutz
>>> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes:
[...]
Patrick> am_libmudfas2d_la_OBJECTS = $(am__objects_1)
Patrick> am_libmudfas3d_la_OBJECTS = $(am__objects_1)
[...]
This will be fixed in Automake 1.6.2. It is already fixed in CVS.
--
Alexandre Duret-Lutz
he list of
dependency files to create out of your Makefile, but it doesn't
know how to evaluate any make variable involved.
Alexander> how can I fix my problem?
Short of a real fix, you could drop `subdir-objects' or stop
using these variables (instead, repeat the relative path for
each source).
--
Alexandre Duret-Lutz
>>> "Paolo" == Paolo Casciello <[EMAIL PROTECTED]> writes:
[...]
Paolo> My problem is grouping one (or more) library in another library.
Paolo> Is it possible?
I think Libtool can do this.
[...]
--
Alexandre Duret-Lutz
LAGS'
Glenn> It's complaining about a couple variable names used by lftp that have
Glenn> nothing to do with automake; why's it doing this? (I can work around
Glenn> this by renaming these variables, but it's annoying.)
This was fixed in Automake 1.6.1
--
Alexandre Duret-Lutz
[...]
>> > Ahh, this is c++, and I have tried ui_CPPFLAGS...
>>
>> You should use ui_CXXFLAGS then. CPPFLAGS is flags to pass to the
>> pre-processor.
Ralf> -D flags are pre-processor flags, so CPPFLAGS is appropriate.
Unfortunately Automake doesn't support per-target _CPPFLAGS.
[...]
--
Alexandre Duret-Lutz
b.h: y.tab.c' dependency by
y.tab.h: y.tab.c
if test ! -f $@; then \
rm -f y.tab.c; \
$(MAKE) y.tab.c; \
fi
(Automake does something similar in the handling of config.h
already.)
What do you think? Would this be enough for you?
[...]
--
Alexandre Duret-Lutz
>>> "Frederico" == Frederico Faria <[EMAIL PROTECTED]> writes:
Frederico> I have any .mk files that I could like to add to the
Frederico> Makefiles generated by configure.
Do these files exist before Automake is run, or are they created
by configure?
[...]
--
Alexandre Duret-Lutz
27; which is valid for test_LDADD,
but not for test_SOURCES.
So you have to set test_DEPENDENCIES yourself, from your
Makefile.am:
test_SOURCES = test.c
test_LDADD = $(LIBTEST)
test_DEPENDENCIES = $(LIBTEST)
[...]
--
Alexandre Duret-Lutz
handling of _OBJECTS variables for targets sharing source variables.
- Check dependency mode for Java when AM_PROG_GCJ is used.
--
Alexandre Duret-Lutz
into Makefile.am: Automake will create a Makefile.in including
rules from both files.
I don't know if that's really what you want; I'm confused by
your last answer.
[...]
--
Alexandre Duret-Lutz
701 - 800 of 920 matches
Mail list logo
