ll-script-test`
Bruce> if test $? -eq 0
Bruce> then
Bruce> AM_CONDITIONAL([XXX], [true])
Bruce> else
Bruce> AM_CONDITIONAL([XXX],[false])
Bruce> fi]
[...]
--
Alexandre Duret-Lutz
h . . . no
Meussen> configure: error: Autoconf 2.58 or better is required.
Could you post config.log?
--
Alexandre Duret-Lutz
>> or simply
>>
>> bin_PROGRAMS=goodbye
>> include $(top_srcdir)/extra.am
>>
>> and extra.am needs to add one file to CLEANFILES in both cases.
Stepan> well, I see two ways:
A third one is
AC_SUBST([CLEANFILES], [''])
and both fragments should work without modification.
--
Alexandre Duret-Lutz
lly; check
unconditionally and only perform conditional actions ».
I know that unfortunately AC_PROG_CXX does not allow conditional
actions (since it abort if no compiler is found), but calling it
conditionally as above is just what causes AM_CONDITIONAL to be
called conditionally (and thus, fail at configure time).
--
Alexandre Duret-Lutz
pan> Safety, I guess.
http://sources.redhat.com/ml/bug-automake/2004/msg00656.html
--
Alexandre Duret-Lutz
>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> On Thu, 2005-01-13 at 21:12 +0100, Alexandre Duret-Lutz wrote:
>> >>> "Meussen" == Meussen Erik IT415 <[EMAIL PROTECTED]> writes:
[...]
Meussen> checking whether
up recursive
targets with GNU make. Option -C is neither portable nor
standard.
How about the following patch to Automake?
The very last paragraph of check4.test shows how I was able to
reproduce the problem with GNU make (without cygwin
modifications).
2005-01-15 Alexandre Duret-Lutz
>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> On Sat, 2005-01-15 at 13:15 +0100, Alexandre Duret-Lutz wrote:
>> PS: I know this is not the first time, but I simply do not
>> understand why you respond to bug reports without Cc: the
&
ams and their version automake required for
Ben> installation. I know configure will generally tell you,
Ben> but it would be nice to be able to check a file
Ben> first. Just a thought.
Perl >= 5.005_03
Autoconf >= 2.58
should be all we expect
--
Alexandre Duret-Lutz
t
Leonardo> could conflict with a possible ``clean-local'' in the Makefile.am.
Leonardo> Any ideas?
clean-local:
rm -rf $(MYCLEANFILES)
--
Alexandre Duret-Lutz
ind this. Things are moving, but
slowly.
Please see (in that order):
http://lists.gnu.org/archive/html/bug-gnu-utils/2004-11/msg00099.html
http://lists.gnu.org/archive/html/bug-hello/2004-12/msg8.html
http://www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/autotools.html
--
Alexandre Duret-Lutz
you should simply
state so in your Makefile.am:
http://sources.redhat.com/automake/automake.html#Libtool-Modules
--
Alexandre Duret-Lutz
>>> "Jonas" == Jonas Geiregat <[EMAIL PROTECTED]> writes:
Jonas> Hi,
Hi,
What versions of Autoconf & Automake do you use ?
What does `autereconf -vfi -Wall' print?
--
Alexandre Duret-Lutz
On Sat, Jan 29, 2005 at 11:12:49AM -0800, Bruce Korb wrote:
> What does this mean?
The same as the last time you asked, I guess.
http://lists.gnu.org/archive/html/autoconf/2003-06/msg00085.html
erable slow down.
Why does it "re-read many files"? Shouldn't it just compare
time stamps like make would do? (And if so, why would it be
slower than make?)
Anyway, an idea would be to write a depcomp than use --make and
-M during the first compilation, and use only -M for later
recompilation. That's would be an improvement for all but the
first compilation.
--
Alexandre Duret-Lutz
each time a
user run ./configure in the source tree it should cause automake
to be rerun to update all dependent Makefile.ins. This implies
your users must have automake installed.
--
Alexandre Duret-Lutz
On Wed, Feb 02, 2005 at 11:46:28AM +0100, Ralf Corsepius wrote:
> MYDIR=$(top_builddir)
> include $(MYDIR)/aminclude.am
This should have the same effect as
include $(top_builddir)/aminclude.am
which Tom is trying to avoid because it is not portable.
If you want to portably include (non-automake
CVS Autoconf at this date, and they have changed a
bit.
--
Alexandre Duret-Lutz
ariable
Stepan> in the top level Makefile.am.
That would be in each Makefile.am: AUTOMAKE_OPTIONS is local,
AM_INIT_AUTOMAKE is global.
--
Alexandre Duret-Lutz
e> and the files COPYING, INSTALL, config.guess and
Bruce> config.sub were not copied into the directory until I
Bruce> directly invoked "automake" with the noted options:
Bruce> automake --gnu --add-missing --copy --ignore-deps -Wall
That would be a bug. Please show us how to reproduce it so it
can be fixed.
--
Alexandre Duret-Lutz
#x27; needs to know
the filename at run-time in order to check whether `Makefile.am'
exists. (In the very hairy case that your setup requires such use
of variables, you will have to tell Automake which `Makefile.in's
to generate on the command-line.)
To summarize:
* Use literals for `Makefile's, and for other files whenever
possible.
* Use `$file' (or `${file}' without `AC_SUBST([file])') for
files that `automake' should ignore.
* Use `${file}' and `AC_SUBST([file])' for files that
`automake' should not ignore.
--
Alexandre Duret-Lutz
o put the license notice at
the end.
--
Alexandre Duret-Lutz
s the old V7 tar format. This is the historical
--
Alexandre Duret-Lutz
equire the Makefile fragment to be
generated? IOW, why not simply `include common-rules.mk'?
--
Alexandre Duret-Lutz
pear to be longer
than some "human tolerance" threshold. Assume a generated file
list and flatten any variable definition with more that 500
characters in a line. This way ordinary variables are still
output exactly as defined.
(I feeling a bit paranoid here; the above scheme is likely to be
overkill.)
--
Alexandre Duret-Lutz
On Wed, Feb 09, 2005 at 06:49:40AM -0800, Bill Moseley wrote:
> On Wed, Feb 09, 2005 at 08:49:57AM +0100, Stepan Kasal wrote:
> > Hi!
> >
> > [BTW, this would be more appropriate for the autoconf list.]
>
> and then configure outputs Makefile with substitutions:
>
> libexecdir = ${exec_prefix}/li
(*note Using `autoreconf':
| (autoconf)autoreconf Invocation.). If you do not want to remember what
| to run and when, just learn the `autoreconf' command. Hopefully,
| replacing existing `bootstrap.sh' or `autogen.sh' scripts by a call to
| `autoreconf' should also free you from any similar incompatible change
| in the future.
Also, AC_PROG_LIBTOOL is the official name of the libtool macro.
AM_PROG_LIBTOOL is deprecated.
--
Alexandre Duret-Lutz
I'm pleased to announce the release of Automake 1.9.5.
This is a bug-fix release, the list of bugs fixed is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.9.5.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.9.5.tar.gz.sig
ftp://ftp.gnu.org/gnu
is found relative to the top source
| directory.
=> use $(top_srcdir).
[...]
Brendan> AC_PROG_INSTALL
Useless call.
[...]
Brendan> AC_CONFIG_FILES([Makefile\
Brendan> src/Makefile\
Brendan> src/pw/Makefile \
Brendan> ])
Useless backslashes.
--
Alexandre Duret-Lutz
>>> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> writes:
[...]
Dalibor> Is there some way to fix that, other than to use a
Dalibor> dist-hook, or make dist in /tmp :) ?
Yes: send a test-case to bug-automake@gnu.org so it can be fixed :)
--
Alexandre Duret-Lutz
o this didn't feel outrageous.
I don't understand this. AFAICT, `AC_SUBST([AM_CPPFLAGS])'
followed by `AM_CPPFLAGS += -DFOO' works out of the box.
(Precisely because &define_standard_variables does call
&define_configure_variable for all AC_SUBSTed variables.)
[...]
--
Alexandre Duret-Lutz
"Uniform
Leonardo> Naming Scheme" node?
Thanks for the suggestion, I'm installing this on HEAD and branch-1-9.
2005-02-26 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* doc/automake.texi (Alternative): Show how to rewrite nobase_
variables using custom dire
d generate the directive file if needed.
(The real motive for this script was that I didn't want to type
my passphrase 4 times to upload Automake. Unfortunately gpg
will not sign several files in batch, and I refuse to have my
passphrase memorized by a long-lasting process such as an
agent.)
--
Alexandre Duret-Lutz
>>> "David" == David Mohr <[EMAIL PROTECTED]> writes:
David> shouldn't that be AC_CONFIG_FILES(Makefile)?
I recent Automake release would have to you that along with
the initial diagnostic you posted. Consider upgrading.
--
Alexandre Duret-Lutz
z.la
When you write
zzz_LDADD = $(ZZZ_LIBS) libzzz.la
automake generates
zzz_DEPENDENCIES = libzzz.la
automatically.
Baurjan> Is there a way to specify that binaries should depend
Baurjan> on the libraries they are linked with (i.e., that a
Baurjan> general LDADD implies general DEPENDENCIES or
Baurjan> generates the respective dependencies automatically)?
This is what happens.
--
Alexandre Duret-Lutz
en if this location was the right one in the
past, and building foo.c in the build directory is a recent
change. In that case the dependency file still have the old
info.
The way to erase dependency info is distclean:
make -k distclean; ./configure; make
--
Alexandre Duret-Lutz
>>> "Harald" == Harald Dunkel <[EMAIL PROTECTED]> writes:
Harald> Whats about a more general case
http://sources.redhat.com/automake/automake.html#Multiple-Outputs
--
Alexandre Duret-Lutz
t;; \
| done
this seems to imply that simply-expanded variables are
re-expanded when they appear inside deferred variables.
If I manually change `DATA = $(dist_my_DATA)' (this is not a
real solution, because this line is generated by Automake) to
`DATA := $(dist_my_DATA)', then the all-am rule passes, but the
test fails later with
make[1]: *** No rule to make target `helloorld', needed by
`install-dist_myDATA'. Stop.
--
Alexandre Duret-Lutz
e name using autoopts.c
>>
>>
Bruce> Since there is no "autoopts_PROGRAM" variable,
foo.c -> foo is a built-in rule in GNU Make.
--
Alexandre Duret-Lutz
>>> "Irek" == Irek Szczesniak <[EMAIL PROTECTED]> writes:
[...]
Irek> I would appreciate your advice on how to fix this problem.
I fixed something similar some weeks ago in CVS, so you might
just wait for the next release.
--
Alexandre Duret-Lutz
rstand the problem with libtool7.test, but the
Jacob> spy.test, I don't fully understand what's going wrong there,
Jacob> as it seems to work if I run it by hand:
[...]
Those transient failures usually occur on NFS mounted
directories, when the client's clock is not synchronized with
that of the server.
--
Alexandre Duret-Lutz
[[gethostbyname ("");]])],
[], [LIBS=$my_ac_save_LIBS ws2_res=no])
AC_MSG_RESULT([$ws2_res])
])
--
Alexandre Duret-Lutz
for all `input.texi',
instead of having to know how texi2dvi works internally.
(I think that's an old idea from Akim.)
--
Alexandre Duret-Lutz
like
to see in many other tools.
Akim> you will most probably not get rid of the silly list of
Akim> hard coded extensions
I would like to. Not now, of course.
--
Alexandre Duret-Lutz
k> I must be missing something obvious.
Maybe. It works fine for me. Could you post a complete test
case with instructions to reproduce your problem?
--
Alexandre Duret-Lutz
On Thu, Jun 23, 2005 at 03:27:18PM +0200, Ralf Wildenhues wrote:
> Hi
>
> * SummoneR wrote on Thu, Jun 23, 2005 at 03:14:40PM CEST:
> > Ralf Wildenhues wrote:
> > >* SummoneR wrote on Tue, Jun 21, 2005 at 07:40:30PM CEST:
> > >
> > >>And if I continue with make && make install and finally try to bu
and the drivers in `cups-config
Roger> --serverbin`/filter. 'make distcheck' has never worked because of
Roger> this.
The FAQ entry `Hard-Coded Install Paths' has some suggestions.
--
Alexandre Duret-Lutz
>>> "Kelley" == Kelley Cook <[EMAIL PROTECTED]> writes:
Kelley> Is an automake 1.9.6 release planned?
I hope to release a beta in couple of weeks, once I've processed
my backlog.
--
Alexandre Duret-Lutz
test. I
generally prefer the extra shell script because it allows me to
run a single test easily.
--
Alexandre Duret-Lutz
Ed> list
Thanks for the report. I'm installing the following fix on HEAD
and branch-1-9.
2005-06-24 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* lib/Automake/Variable.pm (define, _new): Remember the helper
variable created for the last conditional += on each varia
lowing would do the trick.
if condition-for-no-dependency-tracking; then
# disable dependency-tracking by default
enable_dependency_tracking=${enable_dependency_tracking-no}
fi
(this would go before AM_INIT_AUTOMAKE)
--
Alexandre Duret-Lutz
was no error message. But there was no SUBDIRS
Harald> in the generated Makefile, either. The subdirs were not
Harald> built.
Thanks for the report. I'm installing the following fix on HEAD
and branch-1-9.
2005-06-30 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* au
he case going forward.
I believe $-filenames works only with GNU make.
--
Alexandre Duret-Lutz
ll defined from configure via
a substitution, so Automake cannot do any preprocessing on its
contents.
--
Alexandre Duret-Lutz
m4_sinclude.
(PR/450)
* Other miscellaneous changes:
- Update the GPL license, and the FSF postal address.
- Anticipate for python2.5 in AM_PATH_PYTHON.
- The manual should now compile without any warning from TeX.
--
Alexandre Duret-Lutz
pgplO3M3aELB1.pgp
Description: PGP signature
-1.9.5b.tar.bz2.sig
ftp://sources.redhat.com/pub/automake/automake-1.9.5b.tar.gz
ftp://sources.redhat.com/pub/automake/automake-1.9.5b.tar.gz.sig
ftp://sources.redhat.com/pub/automake/automake-1.9.5b.tar.bz2
ftp://sources.redhat.com/pub/automake/automake-1.9.5b.tar.bz2.sig
--
Alexandre Duret-Lutz
sence of
conditional headers, and impossible in presence of AC_SUBSTed
headers. As for why $(includedir) is precreated, I don't know
whether that is a feature or not (it makes a difference when
nobase_include_HEADERS is empty).
--
Alexandre Duret-Lutz
n filenames, including colons and
pds> whitespace as well as dollar signs.
Excellent! That seems to be the ticket, doesn't it?
--
Alexandre Duret-Lutz
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
pds> I don't know whether automake currently works correctly
pds> for Java with any other version of make, but this would
pds> definitely cause that not to be the case going forward.
I'm pleased to announce the release of Automake 1.9.6.
This is a bug-fix release, the list of bugs fixed is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.9.6.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.9.6.tar.gz.sig
ftp://ftp.gnu.org/gnu
>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
[...]
Bruno> all-local $(libfoo_la_OBJECTS): $(ARGZ_H)
Hmmm, why do you need this since $(ARGZ_H) is already in
$(BUILT_SOURCES), and "all" depends on $(BUILT_SOURCES)?
--
Alexandre Duret-Lutz
m someone having access to such a host.
http://lists.gnu.org/archive/html/automake-patches/2005-07/msg9.html
--
Alexandre Duret-Lutz
libnetcdf.la
EH> ...
EH> Is there a better way to do this? Specifically, one which doesn't
EH> require me to explicitly list the dependency program for each and
EH> every test program that depends on it.
[...]
I'm installing the following on HEAD and branch-1-9.
2005-07-2
such part-of-file-name-variables are allowed, we also
have to deal with the case where they are conditionally defined.
--
Alexandre Duret-Lutz
S", assuming
this is a inference rule for *.idlC -> *.cpp
However if you say
SUFFIXES = .idl C.cpp
.idlC.cpp:
whatever
then this will be correctly understood as a rule for *.idl -> *C.cpp
So we could say that `.' is not magic as long as there are some
SUFFIXES matches.
--
Alexandre Duret-Lutz
I$(MYLIB)/include
HD> PreciousUtils_checker_LDADD = \
HD> -L$(MYLIB)/lib -lmylib
Not with the current parser. I think if you just give up the
habit to use tabs inside variables definitions you should be
safe. (I use 2 spaces.)
tabs are the only way for Automake to recognize rules.
executing the dejagnu tests?
Just add your own rule that depends on $(check_PROGRAMS):
.PHONY: check-norun
check-norun: $(check_PROGRAMS)
and type `make check-norun' instead of `make check'.
Or if you just need to disable the dejagnu tests occasionally,
try something like
make check
>>> "DM" == D M <[EMAIL PROTECTED]> writes:
DM> Hello.
DM> Is is perfectly legal to have following conditional in
DM> Makefile.am:
DM> if SOMETHING
DM> install-data-local:
DM> anything
DM> endif
Yes.
--
Alexandre Dure
>>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes:
SK> Alexandre, will you accept it?
Sure. It just needs the usual stuff for a new feature: some
documentation, and a test case that shows it (will continue to)
works as documented.
--
Alexandre Duret-Lutz
ne
implementation of AC_SUBST offer a kind of horrible way to introduce
a make rule in ALL Makefiles, since you could have
DUMMY = @DUMMY@
substituted by
DUMMY =
mytarget: mydependency
my rule
Eww :)
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
btool would build a convenience library
(as documented).
Whether libtool -rpath will eventually be passed down to the
linker is libtool's decision; nothing automake should be
concerned with. I'm not aware of any way to interfere with
this, but perhaps you should check the archives of the
e of a file?
Sorry for not answering this question (I don't know the answer),
but why test only the size ? Isn't the contents important too ?
If the file isn't too big I'd ship the expected result and
compare it with `cmp'. If it's too big you can still compu
' \
INCDIR='$(top_srcdir)/src' \
$(SHELL) $(srcdir)/includes.test
installcheck-local:
CXX='$(CXX)' \
CPPFLAGS='-I$(includedir) -I$(pkgincludedir) $(LIBGSPN_CPPFLAGS) $(CPPF
LAGS)' \
CXXFLAGS='$(AM_CXXFLA
o I've installed the following patch to
gather everything in one place.
2006-01-05 Stepan Kasal <[EMAIL PROTECTED]>
Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.in (top_srcdir): New global.
(generate_makefile): Compute it.
(fi
another implicit rule.
Maybe your declaration of BUILT_SOURCES avoids such problems,
but anyway I think it would be safer to write implicit rules
that depend on existing files (*.ui) rather than built files
(*.h) when possible.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
help2man --output=$@ $(top_builddir)/src/foo$(EXEEXT)
BR> And finally, at the bottom of that section I may have found an error in
BR> the documentation.
Thanks, I'm installing this.
2006-02-05 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* doc/automake.tex
@if test ! -f \$@; then \
rm -f src/foo.cxx; \
$(MAKE) $(AM_MAKEFLAGS) src/foo.cxx; \
else :; fi
DG> Should I even be using the .fl.cxx suffix
DG> rules as I am doing at the moment, or should I be using SUFFIXES?
SUFFIXES is something you use in addition to suffix rules to support
weird extensions (not starting with one dot, or with more than one).
Not your case.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
/input/scan.ll \
tf> $(srcdir)/util.cpp
tf> parser_SOURCES = \
tf> $(srcdir)/input/grammar.ypp \
tf> $(srcdir)/input/scan.ll
Those $(srcdir)/ prefixes everywhere seem pointless to me, I'd remove them.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
live with it and fetch
headers and libraries from where they lie. Besides libtool
libraries (assuming that's what you build) are not something I'd
ever want to move in a build tree.
Or maybe each of you subpackage could supply a script run by the
top-level configure to build symlinks,
Did you read section "Handling Local Macros" of the Automake manual?
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
adding support for new languages into
VG> autoconf/automake/libtools?
The developer's documentation is the code and the mailing list
archives. If you plan in contributing to Automake, please start here:
http://sources.redhat.com/automake/contribute.html
I'll send you the assignment fo
which generate some of
DM> these files into a maintainer-mode only section?
If you show us your setup someone might be able to suggest changes
that do not involve the infamous maintainer-mode.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
>>> "TM" == Tommi Mäkitalo <[EMAIL PROTECTED]> writes:
TM> Can you tell me, where I might find these patches, since Vadim seems to be
TM> offline. I would like to look at them.
http://www.google.com/search?q=automake+ada+patch
--
Alexandre Duret-Lutz
Shared
libraries can be used to setup the
kind of hierarchical layout you described, and they can be
used to build static or shared libraries as well as when
linking program
- so I guess all you need is a libtool switch to ask
for a relocatable output.
Then you'd w
#x27;m installing the following patch.
2006-03-25 Mike Frysinger <[EMAIL PROTECTED]> (tiny change)
Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* aclocal.in ($m4_include_rx): Do not recognize `include', and
adjust scan_configure_dep and scan_file accordin
le that is just as
| simple as my example
Sure. See this tutorial
http://www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/autotools.html
slides 86 (VPATH builds) and 87 (using a library like you did).
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
this Makefile.am:
CXXFLAGS = @CXXFLAGS@ $(MYHACK)
and then AC_SUBST MYHACK to either -O0 or nothing.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
Eric:
| Is there any way you might consider dropping the
| Front and Back Cover Texts requirements from the manual?
Sorry, this is the FSF policy. Not my call.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
ange that it be
only performed inside AM_INIT_AUTOMAKE.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
t: I'd be fine
with this, but it just looks like a complicated way to retrieve
a version number.
Any cunning idea ? Or can we tweak Autoconf to make its version
more accessible ?
2006-04-13 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* aclocal.in (trace_used_macros): R
>>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes:
SK> Hello,
SK> On Thu, Apr 13, 2006 at 08:52:48PM +0200, Alexandre Duret-Lutz wrote:
>> Or can we tweak Autoconf to make its version more accessible?
SK> what would be wrong with parsing `autocon
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> Here is my attempt at checking Autoconf version in aclocal.m4.
adl> It would be nice if someone could suggest a better way to retrieve
adl> the Autoconf version:
Here is a second attem
rule to rebuild one
Makefile.in with a new Autoconf version, all the other
Makefile.ins remain based on the other Autoconf version
- if autoconf is called by the rebuild rule of configure
then nothing guarantees that the existing Makefile.ins
are compatible.
--
Alexandre Duret-Lutz
r your Makefile{,.in,.am}. This GNUmakefile
would look as follows :
include Makefile
% : RCS/%,v
% : %,v
This way GNU Make will uses these rules in addition to the
ordinary Makefile. But Automake and other Make implementation
never see them.
[...]
RH> CO = \#
BTW, escaping # is not porta
are special variables that list
programs that the resulting `Makefile' should build. In Automake
speak, this `_PROGRAMS' suffix is called a "primary"; Automake
recognises other primaries such as `_SCRIPTS', `_DATA', `_LIBRARIES',
etc. corresponding to different type of files.
The `bin' part of the `bin_PROGRAMS' tells `automake' that the
resulting programs should be installed in BINDIR. Recall that the GNU
Build System uses a set of variables to denote destination directories
and allow users to customise these locations (*note Standard Directory
Variables::). Any such directory variable can be put in front of a
primary (omitting the `dir' suffix) to tell `automake' where to install
the listed files.
Programs need to be built from source files, so for each program
`PROG' listed in a `_PROGRAMS' variable, `automake' will look for
another variable named `PROG_SOURCES' listing its source files. There
may be more that one source file: they will all be compiled and linked
together.
Automake also knows that source files need to be distributed when
creating a tarball (unlike built programs). So a side-effect of this
`hello_SOURCES' declaration is that `main.c' will be part of the
tarball created by `make dist'.
Finally here are some explanations regarding the top-level
`Makefile.am'.
SUBDIRS = src
dist_doc_DATA = README
`SUBDIRS' is a special variable listing all directories that `make'
should recurse into before processing the current directory. So this
line is responsible for `make' building `src/hello' even though we run
it from the top-level. This line also causes `make install' to install
`src/hello' before installing `README' (not that this order matters).
The line `dist_doc_DATA = README' causes `README' to be distributed
and installed in DOCDIR. Files listed with the `_DATA' primary are not
automatically part of the tarball built with `make dist', so we add the
`dist_' prefix so they get distributed. However for `README' it
wouldn't have been necessary: `automake' automatically distribute any
`README' file it encounters (the list of other files automatically
distributed is presented by `automake --help'). The only important
effect of this second line is therefore to install `README' during
`make install'.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
>>> "BP" == Ben Pfaff <[EMAIL PROTECTED]> writes:
BP> I did a quick job of proofreading as I read your chapter.
(And so did Ralf.)
Thanks a lot to both of you !
I'll post the complete patch momently on automake-patches.
--
Alexandre Duret-Lutz
Share
>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
RW> IOW, are you asking when 1.10 will be ready?
I hope I can release a beta for 1.10 this weekend.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
DIR_P) at some point.
- Automake installs an "Hello World!" example package in $(docdir).
This example is used thorough the new "Autotools Introduction"
chapter of the manual.
--
Alexandre Duret-Lutz
pgp6hItITC3oS.pgp
Description: PGP signature
_id=%3c2006%2d08%2d12%2d23%2d45%2d50%2b6381%2badl%40gnu.org%3e
especially section 2.2.6 about VPATH builds.
[...]
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
s. Is this intentional?
Yes. When packages are nested the subpackage doesn't know the
distdir value, it has to be passed by the parent.
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
501 - 600 of 920 matches
Mail list logo
