Re: Chosing between system and builtin library

[Ralf Wildenhues]

Hi Sylvain,

* Sylvain Beucler wrote on Tue, Oct 14, 2008 at 08:55:56PM CEST:
> 
> (I'm not 100% sure this is the right list, please let me know if this
> is the case :))

Good enough, I'd say.

> I'd like to implement something like gettext's inclusion of 'libintl',
> which can be either included in the source tarball (for users), or
> reused from a system library (for distros).
> 
> gettext's implementation looks complicated. Is there an easier way to
> do the job? I'm pretty sure there are some caveats to be aware of when
> specifying the library.

I think so.  FWIW libltdl is similar (but probably even more
complicated).

Anyway, for a start I'd try to use an AC_CONFIG_SUBDIRS in the toplevel
package (ignores non-existent subdirs), a subdir conigure for the
library, and set LIBFOO, LTLIBFOO, INCFOO (or whatever naming)
accordingly in a m4 macro that you ship to use.  The important bit when
using libtool is that you specify (and use) LTLIBFOO as sub/libfoo.la
when internal.  I think the gnulib module havelib can help you.

Hope that helps.

Cheers,
Ralf

magic variables for included fragments (was: Feature request)

[Ralf Wildenhues]

* Akim Demaille wrote on Wed, Sep 24, 2008 at 10:01:01AM CEST:
> Le 23 sept. 08 à 23:08, Ralf Wildenhues a écrit :
>> * Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:
>>>
>>> I'm slowly getting rid of my recursive Makefiles.  Instead I have one
>>> local.mk per directory, and a few Makefile.ams that include them.  Of
>>> course I have to prefix all my file names with the name of the
>>> directory, and I find that this explicit name is actually clutter.  I
>>> don't think automake can be educated to guess by itself where to  
>>> prepend the directory name,
>>
>> I agree that that would be too much magic, and probably too fragile.
>
> Yet that would be wonderful to have a means to tell Automake to make a  
> single large Makefile instead of several ones.  It can't do it all by  
> itself, but if the Makefile.ams are sufficiently complete, it might be  
> doable.  Then the magic from Automake would be mostly to give a local  
> and magic value to $(srcdir) $(builddir) etc.  Which is basically what  
> I'm suggesting here.

Hmm.  I don't see how that would be feasible in practice.  Maybe I would
need a more concrete set of hints.

For example, how can you know whether
  -I$(srcdir)

is relative to the fragment source dir, or the included Makefile.am one?
Likewise '-I..'.

>> Probably you want a set of these:
>>
>> - one for the full relative path to the Makefile.am  (%AMSUB%=foo/bar)
>>  (this one would be '.' if in the same directory)
>> - likewise, including final slash (%AMPREFIX%=foo/bar/)
>>  (needed if the prefix can also be empty, to avoid './')
>> - likewise, but flattened (%AMFLAT%=foo_bar_)
>> - reverse of the full relative path (%AMREV%=../..)
>> - maybe a set of these for only the path to the next included snippet?
>> - would that be enough for all use cases?
>
> Yes, I think it would.
>
> Another option would be to provide local variables, scoped to the  
> current local.mk and the one it includes, with traditional scoping.   
> Automake itself could rely on this to define these magic variables.

How would that be different from my approach?  Maybe I just haven't
understood it yet.

>>  # Yes, it is very ugly and IMNSHO an automake misfeature that
>>  # the next line requires an %AMPREFIX%.  Unfortunately, fixing
>>  # it would break user's scripts.
>>  include %AMPREFIX%bar/local2.mk
>
> Bummer :(

Well.  I'm a bit undecided here myself.

On the one hand, the current documentation explicitly only mentions
the cases
  include $(top_srcdir)/file
  include $(srcdir)/file

and nothing else.  So we /could/ in theory blame it on the user, the
non-prefixed case being undefined before (*and* most users expecting
different anyway).

On the other hand, allowing relative paths in `include' statements but
not in other statements is a bit inconsistent, isn't it?

(What we could do anyway would be to warn if the choice is ambiguous.)

>>  --- foo/bar/local2.mk ---
>>  FOO_FLAGS = -I%AMREV%/include
>
> I would not promote too much AMREV.  In my experience it's always  
> clearer and safer to start from top_src/builddir rather than trying to  
> play these tricks.

Hmm.  Still thinking about cases where you cannot avoid it.  Can you
think of one?  Otherwise, maybe we shouldn't even define it?

>>  bin_PROGRAMS = %AMPREFIX%bar
>>  %AMFLAT%bar_SOURCES = %AMPREFIX%bar.c %AMPREFIX%baz.c
>>
>> Yuck.  That's already quite ugly, nothing I'd want to edit regularly.
>> We could use even shorter abbreviations.  Suggestions?
>
> For a start, if you really do not want to use the $() syntax, maybe we  
> can move to something like %()?  Or $[]?  Provided we give a means to  
> the user to write '$[' when she means it, I'm not sure that would be  
> really such a problem to infringe on the Make "name space".
>
> %FOO% is hard to read when there are many, braces are much easier to  
> read.

Agreed.

> Also, we can stick to $(), but within Automake's "namespace".  Say $ 
> (AMPREFIX) instead of %AMPREFIX%.

I'll follow up on automake-patches with a patch to test.  I didn't get
AM_INC_{SUBDIR,PREFIX,CANON,REVERSE} to work yet, only
AM_{SUBDIR,PREFIX,CANON,REVERSE}.  And I have no documentation yet.  Is
there a volunteer for it?  I fear documentation is the hardest part of
this, by far.  And I still hate the naming, better suggestions dearly
appreciated.

Thanks,
Ralf

Re: Depend on a local library in a different source directory

[Ralf Wildenhues]

Hello Sylvain, Thomas,

Please don't top-post, and please keep the list in Cc:, thanks.

* Sylvain Beucler wrote on Sun, Oct 12, 2008 at 08:44:45PM CEST:
> 
> Is there also a way to automatically (re)build '../mylib.la' when I
> issue 'make' in 'lib/python/'?

put this in lib/python/Makefile.am:

../mylib.la:
cd .. && $(MAKE) $(AM_MAKEFLAGS) $@

This will build the library if it doesn't exist.  If you also want to
rebuild it if it exists but is outdated, then you either need to specify
dependencies in the above rule, too, or make it phony.  Of course the
latter is inefficient, as it will cause an extra make invocation in any
case.

The real solution is to use nonrecursive make, if feasible for you.

Hope that helps.

Cheers,
Ralf

Re: Fixing plural case in Banner

[Ralf Wildenhues]

Hi William,

Thanks for the patch.  Please send further patches to the
automake-patches list.

I found one really minor nit, at a glance:

> --- a/lib/am/check.am
> +++ b/lib/am/check.am
> @@ -86,24 +86,35 @@ check-TESTS: $(TESTS)
>   echo "$${col}$$res$${std}: $$tst"; \
> done; \
>  ## Prepare the banner
> +   if test "$$all" -eq 1; then \
> + tests="test"; \
> + All=""; \
> +   else \
> + tests="tests"; \
> + All="All"; \

How about making that "All " ...

> +   fi; \
> if test "$$failed" -eq 0; then \
>   if test "$$xfail" -eq 0; then \
> -   banner="All $$all tests passed"; \
> +   banner="$$All $$all $$tests passed"; \

... and removing the space after $$All here, so there is no leading
white space (once more instance below)?

>   else \
> -   banner="All $$all tests behaved as expected ($$xfail expected 
> failures)"; \
> +   banner="$$All $$all $$tests behaved as expected ($$xfail expected 
> failures)"; \
>   fi; \
> else \

Also, please note that we have a policy that bugs fixed need tests to
ensure that the bugs remain fixed.  Would you be willing to write such
a test?  (No problem if not, I will do it then.)

If you do, please note that it's probably large enough then that we will
need a copyright assignment for changes from you (more off-list if you
are still interested).

Cheers, and thanks,
Ralf

Re: error building ac378dbab6 on mac os X

[Ralf Wildenhues]

* William Pursell wrote on Thu, Oct 09, 2008 at 10:00:34PM CEST:
> Ralf Wildenhues wrote:
>> * William Pursell wrote on Thu, Oct 09, 2008 at 06:28:18PM CEST:
>>> bash-3.2$ make
>>> CDPATH="${ZSH_VERSION+.}:" && cd ../automake &&   
>>> perllibdir="/Users/williampursell/git/build-automake/lib:./lib"   
>>> "/Users/williampursell/git/build-automake/aclocal" --acdir=m4 -I m4

>> I assume you built the current git tree.  Did you run ./bootstrap in it
>> first?  Did you switch between branches without rerunning ./bootstrap
>> afterwards?

> I am unable to reproduce the error, and all builds fine now.
> I think that I did not bootstrap at all, but used the configure
> script that was in the repository.  I don't undertstand why
> aclocal.m4 and configure are in the repo, and didn't realize
> that I hadn't built them myself from a previous bootstrap.

Ah, ok, then it is clear what happened: when you checked out,
time stamps of the files may have caused the autotools reruns.
It's difficult to prevent.

So what happens then is that the rerun commands don't work
unless a bootstrap has run before at least once.

We could certainly remove generated files from git.  If they
pose very big problems, then we may consider this.  However,
especially for developing Automake it's sometimes good to see
how changed affect the generated Makefile.in files.

Cheers,
Ralf

Re: Questions on exporting functions from a shared library

[Ralf Wildenhues]

* Jef Driesen wrote on Thu, Oct 09, 2008 at 05:26:46PM CEST:
> Ralf Wildenhues wrote:
>> * Jef Driesen wrote on Wed, Oct 08, 2008 at 10:24:46AM CEST:
>>> BTW, what is the reason that when I use mylib_la_CFLAGS = 
>>> -DMYLIB_BUILD,  in Makefile.am, all my object files are named 
>>> "mylib_la-myfile.o"  instead of the regular "myfile.o"?
>>
>> Addressed here:
>> <http://www.gnu.org/software/automake/manual/html_node/renamed-objects.html>
>
> I was already thinking in that direction, but since there is only one  
> target that needs to be build in my case, there is no need to rename  
> object files and I assumed automake would not rename.

Problem is, it would be potentially costly for automake to find out
whether there is only one such object.  And maybe even impossible:
there could be @substituted@ sources, where it's not known a priori
whether they are built or not.

> That's why I  
> curious whether there was another reason that could cause this.

No, AFAIK.

Cheers,
Ralf

Re: error building ac378dbab6 on mac os X

[Ralf Wildenhues]

Hello William,

* William Pursell wrote on Thu, Oct 09, 2008 at 06:28:18PM CEST:
> bash-3.2$ make
> CDPATH="${ZSH_VERSION+.}:" && cd ../automake &&  
> perllibdir="/Users/williampursell/git/build-automake/lib:./lib"  
> "/Users/williampursell/git/build-automake/aclocal" --acdir=m4 -I m4
>  cd ../automake &&  
> perllibdir="/Users/williampursell/git/build-automake/lib:./lib"  
> "/Users/williampursell/git/build-automake/automake" --libdir=lib --gnu
> automake: 
> automake: ## Internal Error ##
> automake: 
> automake: Unknown ?token? `LZMA' (neg = 0)
> automake: Please contact <[EMAIL PROTECTED]>.

Thanks for the report.  Please send other new such reports to the
bug-automake list, if possible (but let's keep this thread here for
now).

I assume you built the current git tree.  Did you run ./bootstrap in it
first?  Did you switch between branches without rerunning ./bootstrap
afterwards?

If neither is the case, then can you give a step by step recipe (best
starting with 'git clone') to reproduce this on your system?

Thanks!
Ralf

mailing list netiquette (was: [automake] Dependency question with _LDADD)

[Ralf Wildenhues]

Hello,

guys, let's please cut this off at this point.  I don't like
top-posting, I don't like it if people don't trim their replies to
only quote what they address.  I spend very little time reading most
messages, and am very likely to just drop those that are sloppily
written, unreadable, un-understandable, deal with many essentially
separate topics at a time, don't adjust the Subject (to the point
that it's useless to look at).

I can't speak for others, but I suspect there are many more readers
here who prefer civilized, high-content, low-noise discussions.
Please remember that there are many readers here (we can't know but
it's certainly in the hundreds), and work you burden on them is
multiplied, so shifting the burden to the message writer is the
efficient thing to do.

For everyone who doesn't know what that all means, here are some
helpful links to read:
,
.

This thread, and some others, recently (I'm not trying to single out
anyone here), lack obvious signs that the authors have engaged in
searching the mail archives at
 or
 for prior discussions;
this can lead to long-time readers of this list just ignoring the
threads, due to lack of new content.  On the positive side,
references to the manual are given in this thread (which is good!).

Cheers,
Ralf

Re: Questions on exporting functions from a shared library

[Ralf Wildenhues]

* Jef Driesen wrote on Wed, Oct 08, 2008 at 10:24:46AM CEST:
>
> I am shipping the symbols file. In my Makefile.am, I have
>
> EXTRA_DIST = mylib.symbol
>
> to make sure the file is included in the tarball.
>
> But with this approach, msvc users will need to (manually) generate a  
> DEF file from it. And that is something I would like to avoid.

Hmm.  I suppose shipping the DEF file for them (for one setup?) won't
work?

>>> Note: How do can I detect whether the visibility attribute is supported?
>>
>> For example with the gnulib module 'visibility'.
>
> How do I use this visibility.m4 file? Do I need to copy its contents  
> into my configure.ac file?

No, you ship it additionally; see the AC_CONFIG_MACRO_DIR description here:


Typically, you just import the whole gnulib module:


> BTW, what is the reason that when I use mylib_la_CFLAGS = -DMYLIB_BUILD,  
> in Makefile.am, all my object files are named "mylib_la-myfile.o"  
> instead of the regular "myfile.o"?

Addressed here:


Cheers,
Ralf

Re: Fortran projects (was: Compilation order)

[Ralf Wildenhues]

* Alberto Luaces wrote on Wed, Oct 08, 2008 at 08:53:54PM CEST:
> 
> Thank you very much for the information, I'm currently perusing it. Is this 
> the right list for asking implementation questions?

Yes.  automake-patches is for discussing patches; if the topic is
less interesting for users of Automake and rather a topic for Automake
developers only, then it is better to move there.

Cheers,
Ralf

Fortran projects (was: Compilation order)

[Ralf Wildenhues]

Hello Alberto,

* Alberto Luaces wrote on Mon, Oct 06, 2008 at 05:11:42PM CEST:
> El Domingo 05 Octubre 2008ES 11:23:40 Ralf Wildenhues escribió:
> > Before you implement manual dependency tracking in your own project:
> > how about implementing it in Automake, so that all Fortran projects can
> > benefit?

> Although I'm a automake newbie, I am interested. I'd be grateful if you gave 
> me those pointers.

> > BTW, is this header dependencies for preprocessed Fortran, or Fortran 90
> > module dependencies?
> 
> This project has only f90 module dependencies, although I also have other 
> older f77 projects that use include files, so I could test both. My idea was 
> to program a Perl script that could find what source files contain which 
> modules and then, in a second pass, write the dependencies of every file 
> given the modules they use. At a later stage, that Perl script could be 
> converted to a shell + sed script if it is needed.

There are two projects for Automake lurking here:

1) support header dependencies for preprocessed Fortran.
This should be a reasonably straightforward extension of side-effect
dependencies currently implemented for C and C++, for example.  The key
ideas are described here:
<http://www.gnu.org/software/automake/manual/html_node/Dependency-Tracking.html>
<http://www.gnu.org/software/automake/manual/html_node/Dependency-Tracking-Evolution.html>

Most that would be needed for ppfc, ppf77 is an adjustment of the
depcomp script for the various ways that can header dependencies
can be output.  And a couple of changes in automake.in to actually
enable this for these languages, and tests to make sure this works.

Norman Gray has done some prior work here IIRC.  Maybe we can just reuse
some of his.


1.5) Well, there is at least one special case issue we should address
separately.  Part of testing (1) would be to check that config.h
inclusion as well as -D settings from DEFS work.

Now, the IBM xlf/xlf90 compiler rejects -DDEFINE but accepts
-WF,-DDEFINE instead.  This can be worked around, either by
some clever substitutions in the makefile, or with a wrapper
script a la `compile', let's call it fppcompile.

(I think I even have a half-baked patch for this lying around somewhere,
the solution strategy seems so familiar.)

1.75) (If there is need for '-c -o' emulation for deficient Fortran
compilers, I definitely have a half-baked patch for that issue.)


2) Support for module dependencies.
Prior external work:
<http://www.theochem.uwa.edu.au/fortran/recompile/>
<http://www.theochem.uwa.edu.au/fortran/make_variables>

Problems: compiling foo.f may generate arbitrary modules bar.mod,
baz.MOD, bla.vo.  So the rules may not be simple.  Or we may want to
limit to some kinds of setups: either some compilers only, or some
required naming strategy.  Anyway, the field is quite open here,
but any kind of support would be cool.


Some general comments: if you choose to contribute to Automake, be our
guest, and welcome!  Please note that nontrivial contributions require
copyright assignment (more off-list if you're interested), and please
develop against the git master version of Automake.  Take a look at the
HACKING file for some more helpful bits.

Cheers,
Ralf

Re: Make dist problem

[Ralf Wildenhues]

Hello Laurent,

* [EMAIL PROTECTED] wrote on Mon, Oct 06, 2008 at 02:04:49PM CEST:
> 
> I'm using autoconf 2.61 and automake 1.8 and I've got a probleme with
> the 'make dist' target. 

> He the AC_CONFIG_FILES: 
> AC_CONFIG_FILES( 
> po/Makefile.in 
> Makefile 
> src/Makefile 
> config/gcdk.pc 
> config/gcdk-uninstalled.pc 
> doxygen.cfg 
> test/type/Makefile 
> test/exception/Makefile 
> ) 
> And the two files: test/type/Makefile.in and
> test/exception/Makefile.in are not put into the archive 

How does your SUBDIRS tree look like?  Does the toplevel Makefile.am
list test/type and test/exception, going down two levels at once?
If yes, then updating to a newer Automake is your friend.  1.10.1 is
current, and quoting a NEWS excerpt from 1.9:

|  - The restriction that SUBDIRS must contain direct children is gone.
|  Do not abuse.

Hope that helps.

Cheers,
Ralf

Re: Cross-compiling with automake

[Ralf Wildenhues]

Hello Thomas,

* Thomas Epperson wrote on Mon, Oct 06, 2008 at 12:41:19PM CEST:
> kernel_LDFLAGS = -nostdlib -lgcc -T $(srcdir)/x86/link.ld
> 
> I need to specify nostdlib and lgcc at the same time. But when I do it this
> way, lgcc gets ignored and the functions in it do not get linked in. I think
> this is a problem with the order in which nostdlib and lgcc are called.
> nostdlib gets caught in COLLECT_GCC_OPTIONS while lgcc gets passed to the
> collect2 program (output gathered from the -v flag).

I don't think your issue has to do with automake at all; it rather looks
like a GCC issue.  I can't tell if all you need is to use '-Wl,' or if
there is some limitation in the gcc driver that you need to work around.

> I can do away with the nostdlib option, but that causes undesired libraries
> to be linked in (which is bad).

Maybe --as-needed helps you (see the gnulib module lib-ignore for how to
use it portably).

Hope that helps.

Cheers,
Ralf

Re: Questions on exporting functions from a shared library

[Ralf Wildenhues]

* Jef Driesen wrote on Thu, Oct 02, 2008 at 05:08:55PM CEST:
>
> mylib.exp: mylib.symbols
> if XYZ
>   $(CPP) -P -DMYLIB_XYZ_SUPPORT - < mylib.symbols | sed -e '/^$$/d' > $@
> else
>   $(CPP) -P - < mylib.symbols | sed -e '/^$$/d' > $@
> endif
>
> CLEANFILES = mylib.exp
> EXTRA_DIST = mylib.symbol
>
> One of the downside of this method is that I need to maintain the  
> separate symbols file (not a real issue). But more important is that  
> this setup is not supported by the msvc compiler. That compiler does not  
> export any function by default, unless a DEF file or the dllexport  
> attribute is used. But I don't know if it is possible to do a similar  
> trick for msvc, and generate the DEF file on the fly. And I don't want  
> to maintain two almost identical symbol files.

Can you just ship the symbol file in the source tarball, and use the
shipped file for msvc?  That hampers development of the code with msvc,
but should work for distribution.

> Note: How do can I detect whether the visibility attribute is supported?

For example with the gnulib module 'visibility'.

> where MYLIB_BUILD is always defined when building the library, and  
> MYLIB_STATIC should be defined for static building and linking.

Note that libtool defines PIC for you for the nonstatic code.

> BTW, is it possible to force automake to link my examples against the  
> static library, in case both the static and shared library are build?  
> Now I'm using a separate build tree with ./configure --disable-shared,  
> thus affecting the complete project, when I need statically linked 
> examples.

You can avoid using a separate tree, by adding -static to the link flags
(either to each testprog_LDFLAGS, or AM_LDFLAGS if all tests reside in a
separate directory).

Hope that helps.

Cheers,
Ralf

Re: Conditional Makefile Fragment

[Ralf Wildenhues]

Hello Tom,

* Tom Browder wrote on Sat, Oct 04, 2008 at 02:29:02AM CEST:
> In my Makefile.am I would like to do something like this:
> 
> if ENABLE_PDF
> < 1. lines of normal Make syntax>
> else
> < 2. lines of normal Make syntax>
> endif
> 
> When I try it, all the lines appear in the final Makefile, but the
> false branch is commented out.
> 
> Is there any way to output the true branch and not the false branch?

Well, if ENABLE_PDF is false, the other branch will be commented out.
You can also use
  if !ENABLE_PDF
  this is used if ENABLE_PDF is not true
  endif

Does that answer your question?

Cheers,
Ralf

Re: Compilation order

[Ralf Wildenhues]

* Alberto Luaces wrote on Fri, Oct 03, 2008 at 05:22:04PM CEST:
> 
> I thought so, but I only knew it could be from experience. In this case, I 
> have to rely on the order of the prerequisites since there is no dependency 
> tracking implemented for Fortran.

Before you implement manual dependency tracking in your own project:
how about implementing it in Automake, so that all Fortran projects can
benefit?

I've been wanting to do that for quite a while, but I don't have the
time to pursue this.  If you are interested, I can provide a couple
of pointers.

BTW, is this header dependencies for preprocessed Fortran, or Fortran 90
module dependencies?

Cheers,
Ralf

Re: Running Custom Commands

[Ralf Wildenhues]

Hi Lalit,

* Lalit Seth wrote on Fri, Oct 03, 2008 at 07:10:24AM CEST:
> 
> I have few source c++ files which are generated by .ice files using
> slice2cpp. How can I do this in Makefile.am? Where I can call
> slice2cpp to generate these source file.

More or less like you would in a normal makefile:

SLICE2CPP = slice2cpp
.ice.c++:
$(SLICE2CPP) args munging $< to $@
SUFFIXES = .ice .c++

You want to list the .ice files in EXTRA_DIST, and depending on whether
you require your users to have slice2cpp, the generated c++ files either
in nodist_foo_SOURCES or foo_SOURCES.

Hope that helps.

Cheers,
Ralf

Re: [PPL-devel] Generating Autotools files without autoreconf

[Ralf Wildenhues]

Hello Roberto, Andreas, all,

* Roberto Bagnara wrote on Wed, Oct 01, 2008 at 06:35:10PM CEST:
> Andreas Schwab wrote:
>> Roberto Bagnara <[EMAIL PROTECTED]> writes:
>>
>>> In other words, we would need something that acts like autoreconf except
>>> for the fact that it would not attempt to build configure from configure.ac.
>>
>> $ AUTOCONF=true autoreconf ...

> it would have been nice and simple, but it does not work.
[...]
> $ AUTOCONF=true autoreconf
> configure.ac:29: error: Autoconf version 2.60 or higher is required
> configure.ac:29: the top level
> autom4te: /usr/local/bin/m4 failed with exit status: 63
> aclocal: autom4te failed with exit status: 63
> autoreconf: aclocal failed with exit status: 63

Yes that is because the other tools run autom4te from Autoconf under the
hood.

Can you install a recent-enough Autoconf under another prefix, or maybe
with --program-suffix=-2.62, and set the variables accordingly, e.g.,
  AUTOCONF=autoconf-2.62 AUTOM4TE=autom4te-2.62 \
  AUTOHEADER=autoheader-2.62 autoreconf

?  Another possibility is to put all generated files under version
control (until GCC has been updated to newer autotools as well).

Cheers,
Ralf

Re: Questions on exporting functions from a shared library

[Ralf Wildenhues]

Hello Jef,

* Jef Driesen wrote on Tue, Sep 23, 2008 at 08:44:47PM CEST:
> Brian Dessent wrote:
>> There are two aspects to the symbol visibility stuff:
[ snip nice explanation ]

> Now that I start to understand all the differences, I only need to find  
> a way how to incorporate everything nicely in my automake build system.  
> Suggestions? I guess I'm not the first one struggling with this, so I'm  
> surprised there is not more information available. Most projects (at  
> least the ones I checked) seems to be using -export-symbols.

Well, as you don't seem to say exactly what you need: you can
- add -export-symbols* to libfoo_la_LDFLAGS, or
- add visibility annotations right to your source files
  (preferably through a #define so you can factor for different
  spellings).

You can get better help if you describe more precisely what you already
tried, and more importantly, which way you decided to go now.

Cheers,
Ralf

Re: Compilation order

[Ralf Wildenhues]

Hi Paul,

* Paul Smith wrote on Mon, Sep 29, 2008 at 09:48:43PM CEST:
> 
> To be really, really pedantic: even in parallel mode, make (currently)
> always relies on the order in which prerequisites are listed for a given
> target.  However, since make is running them in parallel you can't
> really tell which items might end up running together: it depends on how
> the OS schedules the jobs and how long they take to complete, as well as
> how large your N for -jN is.

Yes; thanks for the clarification.

With parallel make, besides the unreliable completion order, effectively
the algorithm has more of a breadth first logic though.  GNU make's
order-only dependency statements can help.

BTW, while you're here, is there chance for a new GNU make release
soonish with the bug fixed that prevented GCC from using dependency
tracking?  (IIRC it dealt with order-only deps.)

> There is an enhancement request for GNU make that hopes for a
> randomization (to help find missing dependency relationships) of the
> prerequisites.  However this is a large, difficult problem the way GNU
> make is coded.

I've always tried to emulate that with a few 'make -j' or 'make -jN'
with a large N, on a system with as many processors as I can get at.

Cheers,
Ralf

Re: Compilation order

[Ralf Wildenhues]

Hello Alberto,

I see you have solved your specific problem; please allow me a couple of
general comments though:

* Alberto Luaces wrote on Mon, Sep 29, 2008 at 10:26:56AM CEST:
> 
> isn't it assured that the build of the objects listed on a Makefile.am is 
> made 
> in the order of the sources of that file?

No, that is not assured.  Well, that's not the whole truth, but anyway
the gist is that you shouldn't rely on it:

When run in parallel (-jN) mode, make doesn't guarantee any order of
rule execution except that implied by the dependency relations.

When not run in parallel mode, then make does consider prerequisites of
a target in the order listed, i.e., from left to right; it thus traverses
the dependency tree depth first.  However, since automake produces some
of those rules, you cannot fully control the order of the items listed
there.  AFAIK automake doesn't reorder items arbitrarily though.

> My problem is that this library has its source files split into several 
> subdirectories. My first attempt was to list the source files in order in the 
> SOURCES variable and to attach a VPATH declaration at the end of the file 
> containig the rest of the subdirectories. This compiled well, but 
> the "distcheck" target failed because the Makefile couldn't find the sources 
> that weren't on the main source directory.

Yeah, you practically can't use VPATH yourself, as automake already uses
it to list $(srcdir) in it.

> I then removed the VPATH statement and began to write the full path of every 
> source file:
> 
> libfoo_a_SOURCES = a.f90 $(srcdir)/A/b.f90 $(srcdir)/B/c.f90 ...

FWIW, why not
  libfoo_a_SOURCES = a.f90 A/b.f90 B/c.f90 ...

> I could also write a Makefile.am for every subdirectory, but I don't know if 
> this would be an overkill.

This should rarely be necessary.

Please note that, in order to use the subdir-objects mode with Fortran,
you need (yet unreleased) development Automake 1.11a.

Cheers,
Ralf

Re: [automake] Dependency question with _LDADD

[Ralf Wildenhues]

Hello Michel,

* Michel Briand wrote on Sun, Sep 28, 2008 at 11:04:36AM CEST:
> an error that's wonder me :
> 
> $ make
> cd . && /bin/bash /home/michel/svn/exc/autotraining/config/missing --run 
> aclocal-1.10 -I m4
> aclocal-1.10: couldn't open directory `m4': Aucun fichier ou répertoire de ce 
> type

Try 'mkdir m4' in the top source directory.

Hope that helps.

Cheers,
Ralf

Re: parallel testsuite execution

[Ralf Wildenhues]

Let's get back to this issue.  I seem to constantly be about one year
behind everything.

* Akim Demaille wrote on Fri, Oct 26, 2007 at 01:53:20PM CEST:
> >>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> > * Akim wrote: 
>  >> So I would like to be able to write something like
>  >> 
>  >> TEST_SUITES = foo bar
>  >> foo_TESTS = foo1.chk foo2.test foo3
>  >> bar_TESTS = bar1.test bar2.sh bar3.c
>  >> 
>  >> and be able to write on the side rules explaining how to .chk -> .log,
>  >> .test -> .log etc.

Do you want to write those rules yourself?  If yes, why?
Wouldn't it suffice if you specified the tests, then they
would be run with 'make check'?  And regarding suffixes,
would it be sufficient to just specify a number of literal ones?
(see below)

Also, do you need to be able to specify the *sources* of
compiled tests?  Is it not sufficient to use check_PROGRAMS there?

>  >> Maybe instead of _TESTS we could reuse _SOURCES?  That's not
>  >> inconsistent: they are really sources which must be compiled into
>  >> *.log files which are then linked together to produce foo.log and
>  >> bar.log.

The semantics are at least a bit different.  With _SOURCES, you have
several pre-defined suffixes.  Here, it seems you want to be able to
specify freely.

With programs, the set of inputs doesn't change at 'make' time.
With tests, I feel running just a few:
  make check TESTS='just a couple of them'

is quite useful to have, even if you need to write it like this:
  make foo.log foo_TESTS='foo2.test'

Lazy completion, hard errors, are good, $(EXEEXT) should be taken care
of, parallel is good, should all be in portable make.

We should allow for interdependent tests, that would be quite helpful.

What I am currently thinking is something like this:

  TEST_SUITES = foo.log bar.log
  foo_log_TESTS = foo1.chk foo2.test foo3
  foo_log_SUFFIXES = $(EXEEXT) .chk .test
  bar_log_TESTS = bar1.test bar2.sh bar3
  bar_log_SUFFIXES = .test .sh
  check_PROGRAMS = foo3 bar3
  bar3_SOURCES = bar3.c`
  bar3.log: bar2.log

To be able to override TESTS (resp. foo_log_TESTS), it is necessary to
have the individual logs depend dynamically on $(TESTS).  IOW, something
like this would be generated by automake:

  am__foo_log_LOGS1 = $(TESTS:=.log)
  am__foo_log_LOGS2 = $(am__foo_log_LOGS1:@[EMAIL PROTECTED])
  am__foo_log_LOGS3 = $(am__foo_log_LOGS2:.chk.log=.log)
  foo_log_LOGS = $(am__foo_log_LOGS3:.test.log=.log)

(@EXEEXT@ instead of $(EXEEXT) because putting macros there is
unspecified by POSIX; it doesn't work with IRIX make).

This however requires that test logs end up in subdirs (think
TESTS=sub/foo), thus depend on suitable dirstamps.  As if
subdir-objects were the default for TESTS.

Are we on the same page here?

Thanks,
Ralf

Re: automake not descending into subdirectories to create Makefile.in's

[Ralf Wildenhues]

Hello Laura,

* Laura Hughes (lahughes) wrote on Thu, Sep 25, 2008 at 09:44:07PM CEST:
> My directory struct looks like this:
>  
> topdir/
>src/
>src/basic_utilities
>src/ethernet_tests/bc5709_tests
>src/ethernet_tests/bc57711_tests
>src/mezzanine_card_tests
>  
> My files:
> topdir/configure.ac:
> AC_PREREQ(2.59)
> AC_INIT(cisco_diags, 1.0.1)
> AC_CONFIG_SRCDIR([Makefile])

The Makefile file is not actually part of the source tree: it is
generated by configure in the build tree (from the Makefile.in file in
the source tree).  So it's better to list some file like a .c file:
  AC_CONFIG_SRCDIR([src/basic_utilities/show_hardware_info.c])

> AM_CONFIG_HEADER([src/include/diags_config.h])
> AM_INIT_AUTOMAKE(no-installinfo, no-installman, nostdinc,
> no-texinfo.tex)

Automake's options need to be listed space-separated here.
I think the commas will pretty much cause it to ignore all
but the first option.

> AC_CONFIG_SUBDIRS(src)

Do you actually need this?  It is necessary only if you have another
configure script in src/.

> # Checks for programs.
> AC_PROG_CC
> AC_PROG_INSTALL
> AC_PROG_RANLIB
[...]

> AC_CHECK_FUNCS([strchr strrchr strtol])
>  
> AC_CONFIG_FILES([Makefile
>  basic_utilities/Makefile
>  ethernet_tests/Makefile
>  ethernet_tests/bc5709_tests/Makefile
>  ethernet_tests/bc57711_tests/Makefile
>  mezzanine_card_tests/Makefile])

It looks like you should list
  src/Makefile

here, too.  Wait: wouldn't that be 
  src/ethernet_tests/Makefile

instead of
  ethernet_tests/Makefile

and likewise for the other Makefiles?  That explains the errors you are
seeing.

> AC_OUTPUT

> topdir/Makefile.am
> AUTOMAKE_OPTIONS = foreign

You don't need this line if you add
  foreign

to the list of options as argument to AM_INIT_AUTOMAKE in configure.ac.

> EXTRA_CFLAGS = @EXTRA_CFLAGS@

You don't need this line if you put
  AC_SUBST([EXTRA_CFLAGS], ...)

in configure.ac.

Same issues in the other Makefile.am files.

> AM_CFLAGS = -Wall -W -Wstrict-prototypes $(EXTRA_CFLAGS)
> SUBDIRS = src
>  
> topdir/src/Makefile.am
> AUTOMAKE_OPTIONS = foreign
> CC = @CC@

You don't need this line.

> EXTRA_CFLAGS = @EXTRA_CFLAGS@
> AM_CFLAGS = -Wall -W -Wstrict-prototypes $(EXTRA_CFLAGS)
> SUBDIRS = basic_utilities ethernet_tests mezzanine_card_tests
[...]

> configure.ac:25: required file `basic_utilities/Makefile.in' not found
> configure.ac:25: required file `ethernet_tests/Makefile.in' not found
> configure.ac:25: required file `ethernet_tests/bc5709_tests/Makefile.in'
> not found
> configure.ac:25: required file
> `ethernet_tests/bc57711_tests/Makefile.in' not found
> configure.ac:25: required file `mezzanine_card_tests/Makefile.in' not
> found

Hope that helps.

Cheers,
Ralf

Re: Feature request

[Ralf Wildenhues]

Hi Ben,

* Ben Pfaff wrote on Wed, Sep 24, 2008 at 06:51:14PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > I'd really hate to invade make's namespace.  They may come up with this
> > really cool new makefile variable, and we can't use it then.  :-/
> 
> I wonder whether this is a real issue, because Automake cannot
> really use new GNU make extensions anyhow (right?)

Right.

> because it
> writes out portable Makefiles.  And it seems unlikely that POSIX
> would start inventing new Makefile syntax either.

What I meant was: while automake itself cannot use new extensions,
users can (and will) use them, as long as they don't directly conflict
with automake's work.  It would be sad if automake would prevent such
usage.

Cheers,
Ralf

Re: Kdevelop + automake problems

[Ralf Wildenhues]

* Bryan Bennetts wrote on Tue, Sep 23, 2008 at 05:01:21PM CEST:
> >
> > > If I do include the aclocal.m4, the configure *still* kicks off automake
> > > because of a subdirs file that is created by configure being newer than
> > > the configure.in, which the Makefile.in is dependant on.
> >
> > What exactly do you mean by a subdirs file?
> 
> Hmm, seems it *might* be a KDE-ism.  From the Makefile.am :
> 
> 
> $(top_srcdir)/configure.in: configure.in.in $(top_srcdir)/subdirs
>   cd $(top_srcdir) && $(MAKE) -f admin/Makefile.common configure.in ;
> 
> $(top_srcdir)/subdirs:
>   cd $(top_srcdir) && $(MAKE) -f admin/Makefile.common subdirs
> 
> $(top_srcdir)/acinclude.m4: $(top_srcdir)/admin/acinclude.m4.in 
> $(top_srcdir)/admin/libtool.m4.in
>   @cd $(top_srcdir) && cat admin/acinclude.m4.in admin/libtool.m4.in > 
> acinclude.m4
> 

If that subdirs file really is updated by configure, then it's time to
file a bug report against whoever wrote those lines.  Input files to
configure should not be modified by configure.  Further, as already
stated, all files necessary to rebuild configure (in this case at least:
the subdirs file, configure.in.in, admin/Makefile.common (why does
configure.in not depend on it BTW?), admin/*.m4 (same question)).

> Is a fairly impenetrable make target which uses cvs.sh to create a 
> file 'subdirs' which lists the (you gonna love this) sub-directories in the 
> project - dunno why.

Probably to avoid having to write
  AC_CONFIG_FILES([subdir/Makefile])

for each subdir.

> I've attached the tarball of the project so you can peruse at you leisure - 
> it'll be quicker than me quoting bits and pieces randomly.

That attachment got lost on the way, so if there are further important
bits, it may help to put the package online somewhere and post a link
(use a pastebin if you don't have web space).

Cheers,
Ralf

Re: Feature request

[Ralf Wildenhues]

Hi Akim,

* Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:
>
> I'm slowly getting rid of my recursive Makefiles.  Instead I have one  
> local.mk per directory, and a few Makefile.ams that include them.  Of  
> course I have to prefix all my file names with the name of the  
> directory, and I find that this explicit name is actually clutter.  I  
> don't think automake can be educated to guess by itself where to prepend 
> the directory name,

I agree that that would be too much magic, and probably too fragile.

> yet it would be quite easier to have some variable 
> that would expand to the prefix of the included file.

Sounds like a reasonable wish.  Let's look at an example.
Probably you want a set of these:

- one for the full relative path to the Makefile.am  (%AMSUB%=foo/bar)
  (this one would be '.' if in the same directory)
- likewise, including final slash (%AMPREFIX%=foo/bar/)
  (needed if the prefix can also be empty, to avoid './')
- likewise, but flattened (%AMFLAT%=foo_bar_)
- reverse of the full relative path (%AMREV%=../..)
- maybe a set of these for only the path to the next included snippet?
- would that be enough for all use cases?

Example:

  --- Makefile.am ---
  include foo/local1.mk

  --- foo/local1.mk ---
  # Yes, it is very ugly and IMNSHO an automake misfeature that
  # the next line requires an %AMPREFIX%.  Unfortunately, fixing
  # it would break user's scripts.
  include %AMPREFIX%bar/local2.mk

  --- foo/bar/local2.mk ---
  FOO_FLAGS = -I%AMREV%/include
  bin_PROGRAMS = %AMPREFIX%bar
  %AMFLAT%bar_SOURCES = %AMPREFIX%bar.c %AMPREFIX%baz.c

Yuck.  That's already quite ugly, nothing I'd want to edit regularly.
We could use even shorter abbreviations.  Suggestions?

And yes, if the resulting snippets are to be usable also from the same
directory, then most usages need AMPREFIX and not AMSUB, if non-GNU make
should work well, too.  This is probably not easy on users.

> Thanks for the good work!

Thanks for the feedback, and the suggestion.

> [1] whatever the name, but not too long.  Maybe a symbol, $/ for  
> instance.

I'd really hate to invade make's namespace.  They may come up with this
really cool new makefile variable, and we can't use it then.  :-/

Cheers,
Ralf

Re: Questions on exporting functions from a shared library

[Ralf Wildenhues]

* Brian Dessent wrote on Fri, Sep 19, 2008 at 05:18:08PM CEST:
> Jef Driesen wrote:
> 
> > The preprocessor stuff is automated. I only have to maintain a symbols
> > file with a few #ifdef's in it:
> > 
> > mylib_abc
> > #ifdef MYLIB_XYZ_SUPPORT
> > mylib_xyz
> > #endif
> 
> But it's still two places where you have to maintain it, i.e. adding a
> new function means adding it to the header and adding it to the
> proto-.def file.

Extracting symbols lists from sources, including ifdefs, shouldn't be
more than a few lines of awk script.  Alternatively, you can employ
naming discipline and use -export-symbols-regex.  Just for example.

Cheers,
Ralf

Re: per-directory options

[Ralf Wildenhues]

* NightStrike wrote on Fri, Sep 19, 2008 at 08:49:20AM CEST:
> On Thu, Sep 18, 2008 at 5:31 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > * NightStrike wrote on Thu, Sep 18, 2008 at 08:01:19PM CEST:
> >> Does automake yet support doing something like this?:
> >>
> >> mylibdir_LIBRARIES=liba.a libb.b
> >> mylibdir_CPPFLAGS=-m32
> >>
> >> mylibdir_liba_a_SOURCES=a.c
> >> mylibdir_libb_a_SOURCES=b.c
> >>
> >> that is, allowing me to avoid the two lines:
> >>
> >> mylibdir_liba_a_CPPFLAGS=-m32
> >> mylibdir_libb_a_CPPFLAGS=-m32
> >
> > No, I'm afraid.
> 
> I'm guessing that means it's not in anyone's queue, then, either.. :(

I kind of don't see yet how such a feature would have many users.
Certainly seems like a very special idea to me: for example passing -m32
typically invalidates many configure tests (size of types, functioning
of compiler, etc).  Generally, multilib setups are accomplished by
having multiple build trees with different configure options.  For
example GCC with its config-ml.in and AM_ENABLE_MULTILIB, and lots of
support code.

> >> I know I ask about it a lot, and I remember seeing posts about it
> >> awhile ago that looked promising regarding getting that feature.
> >
> > Hmm.  Were there patches?  I don't remember any.
> 
> I guess not.  What language is automake written in?

Perl, plus an interesting invention of .am proto language.

Cheers,
Ralf

Re: per-directory options

[Ralf Wildenhues]

Hello,

* NightStrike wrote on Thu, Sep 18, 2008 at 08:01:19PM CEST:
> Does automake yet support doing something like this?:
> 
> mylibdir_LIBRARIES=liba.a libb.b
> mylibdir_CPPFLAGS=-m32
> 
> mylibdir_liba_a_SOURCES=a.c
> mylibdir_libb_a_SOURCES=b.c
> 
> that is, allowing me to avoid the two lines:
> 
> mylibdir_liba_a_CPPFLAGS=-m32
> mylibdir_libb_a_CPPFLAGS=-m32

No, I'm afraid.

> I know I ask about it a lot, and I remember seeing posts about it
> awhile ago that looked promising regarding getting that feature.

Hmm.  Were there patches?  I don't remember any.

I assume using subdir Makefiles together with AM_CPPFLAGS is out of the
question for you, right?

Cheers,
Ralf

Re: Issue with static linking?

[Ralf Wildenhues]

Hello Micheal,

* Micheal Smith wrote on Mon, Sep 15, 2008 at 11:23:57PM CEST:
> I'm not sure if this is more of a libtool issue, or an automake  
> issue.

Probably neither.

> I have some code that relies on libresolv to do mx lookups.   
> This code uses functions within that library that are not exported  
> unless compiled with the -static flag.

I think the problem is that you shouldn't use these functions.
Find out why you think you need them.  Then get rid of that need.  :-)

One workaround would be to link the program completely static
(-all-static), but I'm guessing it still won't give you the
functionality you need (some of glibc's networking stuff only
works from the shared library).  And of course other functionality,
which you have already found out.

[...]
> gcc -g -O2 -o program main.o auth.o crypto.o errors.o htable.o  
> interface.o llist.o logging.o smtplib.o socklib.o  ./.libs/libmxresolv.a  
> -lssl -lpthread -lpam ./.libs/libmxresolv.a(mxresolver.o): In function 
> `mx_lookup':
> undefined reference to `__ns_initparse'
> undefined reference to `__ns_parserr'
> undefined reference to `__ns_name_uncompress'

Cheers,
Ralf

Re: Incorrect information in the manual about the tar-v7 option

[Ralf Wildenhues]

[  ]

Hello Vincent, all,

Thanks for the report.

* Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST:
> 
> The automake manual (several versions) says about the tar-v7 option:
> 
>  `tar-v7' selects the old V7 tar format.  This is the historical
>  default.  This antiquated format is understood by all tar
>  implementations and supports file names with up to 99 characters.
> 
> This is incorrect.

Well, I think at the time the sentence was written in 2004:

it was likely correct.  It only became incorrect when BusyBox entered
the scene, grew to be widely used, but with limited functionality.
(The whole thread is quite informative.)

> Old versions of BusyBox (such as v1.6.1, currently
> used on Nokia's Internet tablets) don't support this format. See:
> 
>   https://bugs.maemo.org/show_bug.cgi?id=3033

Interesting.  :-/

> Shouldn't tar-ustar be the default instead of tar-v7?

I'm not an expert on tar implementations and their issues,
and what would be a good default nowadays.

Help?  I Cc:ed a couple of people knowledgeable about tar history,
and the automake list.  The question how far autotools should cater
to limitations of new and open source software like BusyBox is quite
a difficult one to answer in general, to me.  Should autotools add even
more workarounds, or should rather simply BusyBox be fixed?  Do added
workarounds here remove the incentive to fix the buggy software there?
How much should the fact that BusyBox is actively developed be taken
into account (unlike, say, pdksh, with its quite stable set of bugs)?

Thanks, and sorry for the wide distribution,
Ralf

Re: Question about automatic generation of GPLv3 COPYING file

[Ralf Wildenhues]

* Brian Cameron wrote on Wed, Sep 17, 2008 at 06:05:57AM CEST:
>
> Indeed, it isn't uncommon for a module to have differing licenses.
> That is pretty normal.  However, I would think that the authors of the
> source code should be the people deciding how their code should be
> licensed, rather than an artifact of the build tools being used.  It
> seems hard to ensure that such differing licenses are indeed compatible
> in any sort of automatic fashion.

Certainly.

> Ralf Wildenhues wrote:
>>
>> You can use 'automake --foreign' or AM_INIT_AUTOMAKE([foreign]) to avoid
>> installing GNU-related files.  Without the 'foreign' option, automake by
>> default installs GNU defaults.  Not just for the COPYING file, but
>> several other things as well.  One of Automake's expressed goals is to
>> create packages that match GNU's rules.
>
> Thanks for the pointer.  I hadn't ever read the "GNU Coding Standards"
> document until you highlighted this point, and I found the document via
> Google.

> If automake's goal is to enforce GNU coding standards, then I could
> understand if it failed to work unless the file is present.  Thus
> forcing the authors to create the file or use the 'foreign' option
> (or not use automake).

Yes.

> However, just populating the file with an arbitrary license seems an
> error-prone way to enforce the standard.

It's not arbitrary.  Actually, until the switch to GPLv3, I cannot
remember anyone complaining about this feature of Automake.  I don't
think anybody ever complained that automake did not cater to BSD-
licensed projects here by default, for example.

This issue really is about setting the defaults in the presence of a
license that is not universally accepted.

>>> It seems a very unfriendly way to
>>> propagate a "viral" style license, and a way that could be really
>>> damaging to some users, and could generate bad feelings about the free
>>> software community.
>>
>> That to me really sounds a bit over the top.  Given there are very easy
>> ways to avoid this, and given that the current mode of operation is
>> documented very clearly, 
>
> While I do agree that it is documented reasonably, many people do not
> always read all related documentation.

The question is: do we need to cater for people who both don't read the
documentation and don't take care of writing a COPYING file themselves?
(Yes, this is a bit pointed.)

> People who might decide to use
> autotools to build non-GNU programs might not be familiar with the
> "GNU Coding Standard" or be aware that automake silently enforces a
> license.

But it doesn't "enforce" it!  It merely adds a sensible default COPYING
file (and what we're discussing is whether that "sensible" is good).  It
doesn't scribble in your README "This package is licensed under GPLv3,
see the COPYING file", neither does it put copyright notices at the top
of your source files.  Really the presence of some license in the
COPYING file is not sufficient to declare the project's license fully,
I think we've already agreed to that.

>> and a COPYING file has forever been installed
>> in the default mode, it would be confusing to many users if automake
>> would stop doing this now.
>
> There might be some confusion.  However, as I already explained there is
> already clearly some confusion about the way it currently works.  Note
> the following bug reports.  Clearly the authors of these modules were
> not aware of the ramifications of automake changing its default license
> to GPLv3:

Were any of them aware of the feature at all?  I.e., that COPYING was
added, but in prior automake versions is contained the GPLv2 text?

> To me, this sort of confusion is really more serious than any confusion
> like "where did my autogenerated COPYING file go".

None of the bug reports were about COPYING files that were gone or
overwritten.  That would be really bad style.

> Putting incorrect
> and unintended licenses in a module is more confusing than putting no
> license.


> As you probably noticed, I work for Sun.  Nobody at Sun has yet made any
> decisions about how automake on Solaris should behave.  I was just
> curious about whether disabling the feature by default might be possible
> so all options can be considered.

Sure.  I would ask you not to change Automake's mode of operation from
the default one, though.

> Currently Sun does not allow GPLv3 code to integrate into Solaris, which
> is why this is a particular issue at Sun.  So, until this issue is
> resolved, I guess Sun will probably have to avoid updating to the latest
> versions of auto

Re: aclocal flags are a pain

[Ralf Wildenhues]

* Behdad Esfahbod wrote on Wed, Sep 17, 2008 at 06:11:15AM CEST:
> Behdad Esfahbod wrote:
> > Reading autoreconf source right now.  I may just switch to it if my testers
> > tell me it works on OS X and msys.
> 
> Ok, I see the following things that I like to be able to do but autoreconf
> does not do currently:

Most of which can be had, or at least worked around, by using the
overriding environment variables AUTOCONF, LIBTOOLIZE, ACLOCAL,
AUTOMAKE, no?

>   * Many autogen.sh scripts I've seen try each of automake, automake-1.10,
> automake-1.9 automake-1.8 automake-1.7 in that order to pick the first one
> available.  I'm sure there's good reason for them doing that.  Perhaps because
> of some stupid packaging by some distro at some time...

Which distro doesn't set plain 'automake' to be the latest version, at
least by default?

> My autogen.sh also
> checks for glibtoolize before libtoolize as I mentioned before.

Hmm, this is one thing that strikes me as a sensible change.

>   * My autogen.sh also checks the version of the available tools against those
> requested in configure.ac.  Would be trivial to do in autoreconf as it already
> traces configure.ac.

Not sure what you're after here.  The tools themselves will bail out
anyway if they are too old (discounting automake 1.4 here).  What's
the gain of having autoreconf bail out?

>   * GNOME packages also need to run intltoolize and gtkdocize.  Would be nice
> to add them in autoreconf.  I can cook a patch if there is interest.

No principled objections.  Is there a simple way to detect whether these
need to be run?

>   * Not sure about this one, but I think autoreconf options --force and
> --install kinda take my flexibility away to apply those to some of the tools
> but not others.  For example we have a hand written INSTALL file in cairo.
> Running "autoreconf --install --force" overrides my INSTALL file.  But I need
> those options for the libtoolize call.

Again, use environment variables to add --force on a case-by-case basis.
Or save and restore INSTALL.  (INSTALL is a debatable point.  There are
good arguments for overriding it, and good ones for keeping it, with
--force.  How to detect whether it was modified by the package author?)

Cheers,
Ralf

Re: Question about automatic generation of GPLv3 COPYING file

[Ralf Wildenhues]

Hello Brian,

Thanks for the feedback.

* Brian Cameron wrote on Mon, Sep 15, 2008 at 09:33:20PM CEST:
>
> I notice that the latest versions fo automake cause a COPYING file to
> be created with the GPLv3 license in them, if the COPYING file does not
> already exist.

Yes.  If you want to keep it at GPLv2, then one good idea is to put the
COPYING file into version control, so that it will already be present
when automake is run.

[...]
> So does this mean that modules like gconf-editor is GPLv3 or the actual
> license as specified in the source files?  This seems confusing.

This is a question for a lawyer, not for this list.  I agree that it's
confusing, but note that there should be both: the license file, and the
copyright notices at the top of each source file.  It is not uncommon
that source trees have files with differing (compatible) licenses, and
carry several license files.

> I am wondering if the behavior of creating a COPYING file (if one
> does not already exist) with the GPLv3 license is intended to be a
> feature or not?  Either way, I would like to encourage the automake
> community to consider removing this feature.

You can use 'automake --foreign' or AM_INIT_AUTOMAKE([foreign]) to avoid
installing GNU-related files.  Without the 'foreign' option, automake by
default installs GNU defaults.  Not just for the COPYING file, but
several other things as well.  One of Automake's expressed goals is to
create packages that match GNU's rules.

> Although I can understand
> that some may support this sort of feature to propagate the GPLv3
> license, I do not think that automatically generating a license via
> autotools is the best way to do this.  It seems a very unfriendly way to
> propagate a "viral" style license, and a way that could be really
> damaging to some users, and could generate bad feelings about the free
> software community.

That to me really sounds a bit over the top.  Given there are very easy
ways to avoid this, and given that the current mode of operation is
documented very clearly, and a COPYING file has forever been installed
in the default mode, it would be confusing to many users if automake
would stop doing this now.

> If the automake community is not agreeable to removing this feature,
> would there be a problem if a particular distro removed the feature of
> automatically creating this file with any particular license?  Is this
> something a distro could do, or does the license of automake forbid
> changing automake in this way?

No, I don't see why the GPLv2+ (the license of Automake 1.10.1) should
forbid such a change.  FWIW, you could make 'foreign' the default.
However, if that causes your packages to not be bootstrapped identically
on other distros, that typically hurts your most important users: those
that are also developers, and re-bootstrap the package on their system.

> Or is there a way to configure the default behavior of automake so
> that a distro can specify how automake should create the default
> COPYING file, or what license (if any) should be used when creating
> it?

Changing the automake sources should be a one-line patch.
Getting this patch into FSF Automake sources will probably
be hard (i.e., I'd guess RMS will likely disapprove of it).

Cheers,
Ralf

Re: aclocal flags are a pain

[Ralf Wildenhues]

Hello again,

* Behdad Esfahbod wrote on Tue, Sep 16, 2008 at 01:40:41AM CEST:
> To use an m4/ dir one has to modify three places:
> 
>   * autogen.sh: add "-I m4" to their aclocal invocation (ok, I know autoreconf
> prolly handles it),

Yes, it does.  What keeps you from using it?

>   * configure.ac: add AC_CONFIG_MACRO_DIR(m4)
> 
>   * Makefile.am: add ACLOCAL_AMFLAGS = -I m4

Again, flexibility: for example gcc in its tree has things like
  ACLOCAL_AMFLAGS = -I ../config -I .. -I .

but its AC_CONFIG_MACRO_DIR is empty in some directories, and m4 or
../config in others.

> This makes no sense.  aclocal should scan configure.ac and pick up the flags,
> and automake should use the configure.ac stuff to generate the correct aclocal
> rerun rule.

Hmmyes, this sounds like a better default than what we have now.
After all, a user that needs to override it can still set
  ACLOCAL_AMFLAGS =

Lemme think about this one.

Thanks,
Ralf

Re: MAINTAINERCLEANFILES for autotools

[Ralf Wildenhues]

Hello Behdad,

Thanks for the report.

* Behdad Esfahbod wrote on Mon, Sep 15, 2008 at 09:57:20PM CEST:
> 
>   * automake should generate rules to add Makefile.in to MAINTAINERCLEANFILES.
> 
>   * automake should generate rules to add config.cache to DISTCLEANFILES.
> 
>   * automake/aclocal/autoheader/libtool/* should cause automake to generate
> rules to add the following files to MAINTAINERCLEANFILES for toplevel dir:
[...]
> I personally also include configure.scan in the list.
> 
> Where build/ is the directory passed to AC_CONFIG_AUX_DIR.

This topic has come up before.  There is general agreement that there
should be a simple way to remove all these files; whether through
maintainer-clean, distclean, or a bootstrap-clean or some other method,
is a technical detail (more important for the implementor than the
user).

Benoit started working on bootstrap cleaning a while ago, but that
work has stalled.  One problem is that it is surprisingly difficult
to remove all files correctly in all the different setups that autotools
support, in such a way that 'make' both finishes cleanly, and doesn't
cause any autotools reruns on the way.  That's why this doesn't exist
yet.  We'll revisit this some time, can't say when though.

> Aside from those, I also find it bothersome to have to list all Makefile.in's
> in configure.ac where it should actually be somehow generated from
> Makefile.am's DIST_SUBDIRS itself (is that what automake uses?).

DIST_SUBDIRS is created from SUBDIRS by default.  The listing in
configure.ac is to create Makefile from Makefile.in, the SUBDIRS
listing is to do the traversal.  I agree that it's most often
duplicated work, but in principle it isn't necessary that all
Makefiles are created from Makefile.am or even Makefile.in files.
To allow for this flexibility, means some redundancy.

Cheers,
Ralf

Re: failure in make check

[Ralf Wildenhues]

Hello Angeline,

* Angeline Gail Burrell wrote on Mon, Sep 15, 2008 at 07:55:19AM CEST:
>
> I'm having difficulting getting automake installed.  It will compile and 
> make, but fails 3 tests (actually fails 6, but 3 of these are expected 
> failures).

> I tried to find out how to fix it online, but without 
> success.  Any help would be appreciated.  I'm running this on a iBook G4 
> with Tiger (upgraded from Panther).  The attachment make_auto.am has the 
> stdout from $make check, while make_auto.tests has the stdout from $make 
> check for tests ausdir2, cond17, lisp3, lisp6, lisp8, and txinfo5 in 
> verbose mode.  The second one was large, so I gzipped them.

Thanks for providing verbose logs of those test failures.  All three
fail after the point emacs is called, but it gives no error message.
The emacs reports itself as:
| GNU Emacs 21.2.1

Can you try out the following, in an otherwise empty directory, and post
all output?  Thanks.

echo "(provide 'foo)" > foo.el
echo "(setq load-path (cons nil load-path))" > script
emacs -batch -q -l script -f batch-byte-compile *.el
echo $?
ls -l

Cheers,
Ralf

Re: In-tree datafiles

[Ralf Wildenhues]

Hello David,

* David Sveningsson wrote on Sun, Sep 14, 2008 at 10:24:34PM CEST:
> Hi, my project has some datafiles that is installed into pkgdatadir. I
> would however like to use the in-tree datafiles when I am developing the
> application.
[...]
> What is the normal way to handle such situations? I mean, I can't be the
> first to have this problem.

Typically, this comes up for the testing part of the package (make
check).  In the simplest case, set TESTS_ENVIRONMENT (used for the
programs listed in the TESTS macro).  Otherwise, you can use a wrapper
script (or scriptlet to be sourced) for your uninstalled programs that
sets an environment variable that overrides the compiled-in value of
DATADIR.  This approach has the advantage of not requiring a compile
when installing.

Hope that helps.

Cheers,
Ralf

Re: upgrading from Automake 1.4

[Ralf Wildenhues]

* Joakim Tjernlund wrote on Sat, Sep 13, 2008 at 03:56:41PM CEST:
> > 
> > Since your code could be exhibiting a different hot spot, and since your
> > code provides a unique chance to compare 1.4 and 1.10 performance rather
> > easily, would you be so kind and make available the 1.4- and the
> > 1.10-using versions of your package for testing automake performance?
> > I can't promise when I get to it, but it seems worth a look.
> 
> hmm, depends on what you need. I can get you the Makefile.am
> files(there are a lot of them) but not the whole source tree.

Hmm, yes, the Makefile.am files will do, plus the configure.{in,ac}
file(s), and any *.m4 macro files needed.  If the tarballs are large,
please consider bzip2'ing them or putting up a link somewhere, thanks.

> FYI, 1.8 also runs slow, about the same as 1.10
> Older(1.5 and 1.6) automake SEGV

Well, there really is no support from this side for older releases.
If someone has simple, obvious fixes to them we can put them in the
git tree, but there will be no more releases for branches before 1.10.

Cheers,
Ralf

Re: upgrading from Automake 1.4

[Ralf Wildenhues]

* Joakim Tjernlund wrote on Sat, Sep 13, 2008 at 02:23:17PM CEST:
> 
> Moving from automake 1.4 to 1.10.1 I notice a big increase in runtime
> for automake.  previously with 1.4 I got around 30 seconds, not I get
> 3 minutes and 45 seconds.  is this normal? Can it be reduced somehow?

Good question.  I'm afraid to say that, not knowing any better, neither
remembering efforts to speed up automake, it is probably "normal".

We have looked at speeding up parts of Autoconf and Libtool before, but
neglected Automake, for my part mostly out of laziness: the other two
had quite a few rather low-hanging fruits to pick.

That said, I have measured at one time that for one large package with
lots of Automake conditionals and many makefiles (OpenMPI), I am aware
that automake spends a lot of time in the code that deals with the
conditionals.  It hasn't bothered me enough yet to look in more detail,
though.

Since your code could be exhibiting a different hot spot, and since your
code provides a unique chance to compare 1.4 and 1.10 performance rather
easily, would you be so kind and make available the 1.4- and the
1.10-using versions of your package for testing automake performance?
I can't promise when I get to it, but it seems worth a look.

Thanks,
Ralf

Re: right way to wrap/intercept submakes

[Ralf Wildenhues]

Hello John,

* John Richetta wrote on Wed, Sep 10, 2008 at 02:23:26PM CEST:
>
> Given the usual issues with recursive make variable definitions, it  
> doesn't appear to be possible to redefine $MAKE as I'd like.

I'll ask you again: go a step backward, and explain the high-level
goal that you would like to achieve, the problem you'd like to solve,
not the low-level means you perceive to be the way to (or not to) go.

Cheers,
Ralf

Re: right way to wrap/intercept submakes

[Ralf Wildenhues]

Hello John,

* John Richetta wrote on Wed, Sep 10, 2008 at 05:12:17AM CEST:
> If I want to execute a script between a top level make invocation and a 
> submake, it appears that the only straightforward way to do it that is 
> likely to be portable and reliable(?) is to redefine $MAKE.  If I  
> understand correctly, the right way to do this is as follows.

That looks really awkward and rather fragile.  Please go back one step
and describe what you really would like to achieve, rather than how you
think it would be best to achieve it.  Maybe there is a better way.

>CommandToExec = "$@"
>...
>Result = exec "${CommandToExec}"
>exit ${Result}

I am not sure if this is to be meta-language, but if it is to be shell,
then it should rather be something like

  # the command is passed in the positional parameters.
  exec "$@"
  exit 1

exec does not return at all if the command can be found and executed.
If the script is continued after the exec, it means the execution
failed.  If it worked, the exit status of the process is that of the
exec'ed command.

Cheers,
Ralf

Re: best way to structure project with an "empty" dir

[Ralf Wildenhues]

Hello John,

please do not top-post, thank you.  (If you don't know what top-posting
means, any search engine does.)

* John Richetta wrote on Wed, Sep 10, 2008 at 01:48:45AM CEST:
> On Sep 9, 2008, at 2:41 PM, Ralf Wildenhues wrote:
>> * John Richetta wrote on Tue, Sep 09, 2008 at 11:32:01PM CEST:
>>> I have a project that has a directory structure like this:
[...]
>>> However, the project has traditionally been structured such that the
>>> final executable resides in subdirectories of AppDir, and the actual
>>> source code primarily resides in subdirs of AppDir.
[...]
>> AppDir/Makefile.am:
>> bin_PROGRAMS = A/proggie_one
>> A_proggie_one_SOURCES = B/source1.c A/sub/source2.c ...
>> AUTOMAKE_OPTIONS = subdir-objects

> Unfortunately, due to a last-minute edit in my original message that I 
> failed to review, I misstated something: the (single) built application 
> executable should reside in AppDir, *not* in any of the subdirectories 
> (as my original mail incorrectly stated).  Sorry for the mistake.

No problem.  In this case make it:
AppDir/Makefile.am:
bin_PROGRAMS = proggie_one
proggie_one_SOURCES = B/source1.c A/sub/source2.c ...
AUTOMAKE_OPTIONS = subdir-objects

> Anyway, your solution of simply listing subdirectories in SUBDIRS,  
> without any targets, in the TopDir Makefile did indeed solve my problem.  
> I was already listing them, but assumed I needed to have some form of 
> binary target listed in my Makefile.am.  I'm not sure if this particular 
> point (that a valid Makefile.am need not explicitly list any targets) is 
> as obvious as it might be in the automake documentation.

I'm not sure either.  But I'll recommend Alexandre's autotools tutorial:
<http://www.lrde.epita.fr/~adl/autotools.html>

Cheers,
Ralf

Re: best way to structure project with an "empty" dir

[Ralf Wildenhues]

Hello John,

* John Richetta wrote on Tue, Sep 09, 2008 at 11:32:01PM CEST:
> I have a project that has a directory structure like this:
>
>   TopDir
> |
> +++
> |||
>   AppDir   other dirs...
>   ||
>   AB
>
> The top level of this project is where one invokes configure and make.  
> However, the project has traditionally been structured such that the 
> final executable resides in subdirectories of AppDir, and the actual 
> source code primarily resides in subdirs of AppDir.

Example:

TopDir/Makefile.am:
SUBDIRS = AppDir ...

AppDir/Makefile.am:
bin_PROGRAMS = A/proggie_one
A_proggie_one_SOURCES = B/source1.c A/sub/source2.c ...
AUTOMAKE_OPTIONS = subdir-objects

There is no reason to build a dummy program with no sources.

Hope that helps.

Cheers,
Ralf

Re: automake generates delete targets twice

[Ralf Wildenhues]

Hello Toralf,

* Ralf Wildenhues wrote on Wed, Jul 30, 2008 at 09:02:01PM CEST:
> * Toralf Förster wrote on Wed, Jul 30, 2008 at 09:26:10AM CEST:
> > 
> > regarding to https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2749 I'm
> > wondering whether at UNIX systems automake could be improved to delete a 
> > target
> > only once.

> AFAICS this is an optimization issue only, not a bug per se.
> I haven't measured, but I bet such an optimization would
> not improve "make clean" time even measureably.
> Prove me wrong and we may have a case.  ;-)
> 
> Hmm, maybe the code will get faster if we avoid the sed
> script when $(EXEEXT) is empty ... will look into that.

Here we go with faster 'make clean' for PROGRAMS with libtool.
Applied to master, and put you in THANKS.

This isn't pressing to go into branch-1-10.

Cheers,
Ralf

2008-09-07  Ralf Wildenhues  <[EMAIL PROTECTED]>

Enhance cleaning of programs in libtool mode.
* lib/am/progs.am (clean-%DIR%PROGRAMS) [?LIBTOOL?]: Fork less
often, avoid removing programs twice if $(EXEEXT) is empty.
* tests/nobase-libtool.test: Also test PROGRAMS, in order to
exercise the code path.
* THANKS: Update.
Report by Toralf Förster.

diff --git a/lib/am/progs.am b/lib/am/progs.am
index cc4cf4a..24fd10f 100644
--- a/lib/am/progs.am
+++ b/lib/am/progs.am
@@ -92,11 +92,13 @@ clean-%DIR%PROGRAMS:
 ## Cleaning the `_libs/' or `.libs/' directory is done from clean-libtool.
 ## FIXME: In the future (i.e., when it works) it would be nice to delegate
 ## this task to `libtool --mode=clean'.
-?LIBTOOL?  @list='$(%DIR%_PROGRAMS)'; for p in $$list; do \
-?LIBTOOL?f=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
-?LIBTOOL?echo " rm -f $$p $$f"; \
-?LIBTOOL?rm -f $$p $$f ; \
-?LIBTOOL?  done
+?LIBTOOL?  @list='$(%DIR%_PROGRAMS)'; test -n "$$list" || exit 0; \
+?LIBTOOL?  echo " rm -f" $$list; \
+?LIBTOOL?  rm -f $$list || exit $$?; \
+?LIBTOOL?  test -n "$(EXEEXT)" || exit 0; \
+?LIBTOOL?  list=`for p in $$list; do echo "$$p"; done | sed 
's/$(EXEEXT)$$//'`; \
+?LIBTOOL?  echo " rm -f" $$list; \
+?LIBTOOL?  rm -f $$list
 
 
 ## -- ##
diff --git a/tests/nobase-libtool.test b/tests/nobase-libtool.test
index bb027c6..4da415b 100755
--- a/tests/nobase-libtool.test
+++ b/tests/nobase-libtool.test
@@ -15,7 +15,7 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
-# Make sure nobase_* works for libtool libraries as well.
+# Make sure nobase_* works for libtool libraries and programs as well.
 # This is just the libtool equivalent of nobase.test, split
 # up for greater exposure of nobase.test.
 
@@ -34,8 +34,12 @@ cat > Makefile.am << 'EOF'
 fooexecdir = $(prefix)/foo
 fooexec_LTLIBRARIES = sub/libbase.la
 nobase_fooexec_LTLIBRARIES = sub/libnobase.la
+fooexec_PROGRAMS = sub/base
+nobase_fooexec_PROGRAMS = sub/nobase
 sub_libbase_la_SOURCES = source2.c
 sub_libnobase_la_SOURCES = source2.c
+sub_base_SOURCES = source.c
+sub_nobase_SOURCES = source.c
 
 test-install-data: install-data
test ! -f inst/foo/sub/libnobase.la
@@ -49,13 +53,14 @@ EOF
 
 mkdir sub
 
-cat >source2.c <<'EOF'
+cat >source.c <<'EOF'
 int
 main (int argc, char *argv[])
 {
   return 0;
 }
 EOF
+cp source.c source2.c
 
 rm -f install-sh
 

Re: Cross-compile tar-1.13

[Ralf Wildenhues]

* Steven Woody wrote on Sun, Sep 07, 2008 at 07:53:43AM CEST:
> On Tue, Sep 2, 2008 at 2:35 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > Erm, have you tried
> >  CC=arm-linux-gcc ./configure
> >
> > yet?

> If I did that, I will get:
> 
> loading cache ./config.cache
> checking host system type... ./config.guess: line 735: ./dummy-3089:
> cannot execute binary file
> ./config.guess: line 999: ./dummy-3089: cannot execute binary file
> configure: error: can not guess host type; you must specify one

And what about specifying both?
  CC=arm-linux-gcc ./configure arm-linux

Cheers,
Ralf

Re: Generate objects in right directory

[Ralf Wildenhues]

* Sebastien REYNES wrote on Fri, Sep 05, 2008 at 04:44:54PM CEST:
> Yes I have read this but I believe this solution don't answer to my
> need. In fact, I must to respect this treeview from root :
> 
> /home/devbdie/
> configure.ac
> Makefile
> Makefile.am
> ...
> /home/devbdie/src/module1/
> Makefile
> Makefile.am
> module1.c
> ...
> /home/devbdie/src/module2/
> Makefile
> Makefile.am
> module2.c 
> ...
> /home/devbdie/obj/module1
> module1.o
> ...
> /home/devbdie/obj/module2
> module2.o
> ...
> /home/devbdie/bin/
> module1
> module2
> ...

Unfortunately, you cannot easily get Automake to do it exactly like this
for you.  What you can do is move the files from /home/devbdie/ to
/home/devbdie/src and then
  cd /home/devbdie/obj
  ../src/configure [OPTIONS...]
  make

then the objects will appear where you want them.  The programs will
appear alongside the objects.  If you need them in /home/devbdie/bin/
as well you could make copies or symlinks there, but note that
Automake's concept of the build tree doesn't fit that well:
/home/devbdie/bin is not below /home/devbdie/obj

If at all possible, you should consider changing your layout though.
Really the way Automake separates trees is quite handy once you get
used to it.

Hope that helps.

Cheers,
Ralf

Re: Automake for other language issue.

[Ralf Wildenhues]

Hello,

* PhilFine wrote on Fri, Sep 05, 2008 at 01:15:05AM CEST:
> 
> .ccvm.o:
>   my_gcc -c -O3 $(GST_CFLAGS) -o $@ $^

Consider making this
  .ccvm.$(OBJEXT):

and please note that $^ is GNU make-specific, but you can use $< here
(if that is the right thing for you to use).

FWIW, I would always wrap stuff like my_gcc in a variable so it can be
overridden on the command line.

> plugin_LTLIBRARIES = libgstvideopip.la
> 
> libgstvideopip_la_SOURCES = gstvideopip.c pip_helper.ccvm
> 
> libgstvideopip_la_CFLAGS = $(GST_CFLAGS) 
> libgstvideopip_la_LIBADD = $(GST_LIBS) 
> libgstvideopip_la_LDFLAGS = $(GST_PLUGIN_LDFLAGS) /opt/local/lib/libccvm.a
> pip_helper.o

Put the library and the additional object in *LIBADD, not *LDFLAGS.
Consider not using an absolute name for the library, your users are
certainly not all going to have the library at that place.  (Even if
you're the only one using this now, plan for later, with many many
users ;-)

A fine point here, which you already seem to have noted: the per-target
compile flags (in this case libgstvideopip_la_CFLAGS) don't apply to the
pip_helper.ccvm file.  That is unfortunate.

If this Makefile.am doesn't list other sources that don't need those
flags, you can simply put them in AM_CFLAGS and avoid renamed objects
that way.

Another note: libtool will be upset that you don't feed it a PIC object
(and it cannot see that you do, even if you do).

> noinst_HEADERS = gstvideopip.h pip_helper.h

Hope that helps.

Cheers,
Ralf

Re: question about htmldir

[Ralf Wildenhues]

Hello Susan,

* susan xie wrote on Wed, Sep 03, 2008 at 10:05:59PM CEST:
> When I use automake command, I got the following error message: 
> 
> automake
> doc/Makefile.am:12: htmldir was already defined in condition TRUE, which 
> includes condition DOXYGEN ...
> configure.ac:5: ... `htmldir' previously defined here
> 
> 
> But in configure.ac:5 (line): A C_INIT(SOFT, 1.0, [EMAIL PROTECTED])
> 
> May you give me any hints on this problem? 

With Autoconf version 2.60 or newer, htmldir is already predefined by
Autoconf.  It's really the AC_INIT code that predefines it.  The NEWS
file of the Autoconf source distribution mentions this, and the manual
lists it here:


Here's what you can do:
- ignore the warning or hide it by passing -Wno-override to automake
  (by adding it to AUTOMAKE_OPTIONS in doc/Makefile.am for example)
- not using your own definition of htmldir any more with new Autoconf
  (you should check if Autoconf's setting and yours are compatible)
- use a different directory variable (html2dir, doxgenhtmldir, together
  with doxgenhtml_DATA or so...)

Hope that helps.

Cheers,
Ralf

Re: Generate objects in right directory

[Ralf Wildenhues]

Hello Sebastien,

* Sebastien REYNES wrote on Wed, Sep 03, 2008 at 05:41:29PM CEST:
> 
> How to generate objects files in a dedicated directory ? When I launch
> the following Makefile.am in my current directory
> /home/devbdie/src/module1, the files *.o are generated in the same
> directory.
> 
> lib_LIBRARIES = libcomc.a
> nodist_libcomc_a_SOURCES = prog1.c prog2.c prog3.c
> 
> Where can I specify a different target object directory ?
> (/home/devbdie/obj/module1 for instance)
> Have I to set a parameter within the file configure.ac ? How can I do ?

Just
  cd /home/devbdie/obj/module1
  ../../src/module1/configure
  make

Please see

and more generally the introductory chapter


Hope that helps.

Cheers,
Ralf

Re: Cross-compile tar-1.13

[Ralf Wildenhues]

Hello Steven,

* Steven Woody wrote on Sun, Aug 31, 2008 at 09:50:26AM CEST:
> On Sun, Aug 31, 2008 at 11:21 AM, Ralf Wildenhues wrote:
> >>
> > Please try
> >   ./configure arm-linux
> >
> > which was IIRC the way to do it with Autoconf 2.13.
> >
> 
> Yes, it is 2.13 automake, I found the information in the comments of
> 'configure' script itself.  But what you told './configure arm-linux'
> did not work neither ( it still use gcc instead of arm-linux-gcc). I
> attached the output for you information, please help if possible.

Erm, have you tried
  CC=arm-linux-gcc ./configure

yet?

Cheers,
Ralf

Re: how to install data directories

[Ralf Wildenhues]

* Matej Tyc wrote on Sun, Aug 31, 2008 at 12:30:12PM CEST:
> So I would suggest to add in the
> datafiles section of the Autoconf manual something like "even if you
> have many datafiles that change their names during developement, you
> have to list them in Makefile.am like showed here... See wildcard FAQ
> section for reasoning"

Good idea.

[ Automake wiki ]
> Well, people come here with the problem and leave with the solution.
> Everyone could spend ~ 15 mins by summarizing describing what he has
> learned and I think that the wiki is usually a good place for such
> things since not everything can go into the manual and it's easier to
> search and it works quite well if it is protected against spam etc.

Well I certainly don't mind putting more things in the FAQ.  We could
start with a patch as you suggested above.  Care to suggest one?

Thanks,
Ralf

Re: how to install data directories

[Ralf Wildenhues]

* Matej Tyc wrote on Sun, Aug 31, 2008 at 05:57:13PM CEST:
> 
> Actually I have noticed that
> nobase_dist_foo_DATA =  takes care about subdirectories
> creation, which is really, really good.  I suggest adding a reminder
> of this to the datafiles section in the automake manual since the
> nobase prefix is very useful for datafiles management...

Care to write a patch?

> However, either approach leaves empty directories after make
> uninstall, how come?

Two reasons: first, one cannot know whether other packages share the
directory.  That could be worked around by using 'rmdir' instead of
'rm -rf', though.  But secondly, the sysadmin may have pre-created
the directories using specific permissions (and owner).  This
information is lost if we remove them.

This behavior is mandated by the GNU Coding Standards.

Cheers,
Ralf

Re: Automake with Pro*C

[Ralf Wildenhues]

Hello Sebastien,

please do not top-post, thank you.

* Sebastien REYNES wrote on Fri, Aug 29, 2008 at 09:37:43AM CEST:
> 
> lib_LIBRARIES = libcompc.a
> libcompc_a_SOURCES = ate_u0002.pc ate_u0008.pc ate_u0009.pc ate_u0100.pc
> INCLUDES = -I$(ORACLE_HOME)/precomp/public -I/usr/include

FWIW, I would not hard-code -I/usr/include into a Makefile.am: you don't
know whether your users even want that to come early, also it's searched
by default so you don't need that unless you need it to come earlier.

More generally, it's better style not to set INCLUDES in Makefile.am at
all, but rather let AM_CPPFLAGS be adjusted from configure tests.

> SUFFIXES = .o .c .pc
> .pc.c:
> $(ORACLE_HOME)/bin/proc -DANSI_PRO_C mode=ansi code=ansi_c lines=yes
> iname=$<
> .c.o:
> $(CC) -c $<

This rule overrides a useful rule which automake will generate for you,
and contain all of the nice other variables like CFLAGS, CPPFLAGS, and
so on.  Also, you don't really need the SUFFIXES setting.

I suggest you do it like this instead:

lib_LIBRARIES = libcompc.a
pcfiles = ate_u0002.pc ate_u0008.pc ate_u0009.pc ate_u0100.pc
EXTRA_DIST = $(pcfiles)
nodist_libcompc_a_SOURCES = $(pcfiles:.pc=.c)
PCC = $(ORACLE_HOME)/bin/proc
PCCFLAGS = -DANSI_PRO_C mode=ansi code=ansi_c lines=yes
.pc.c:
$(PCC) $(PCCFLAGS) iname=$<


That way, things will still work if you use per-target flags for the
library (e.g., libcompc_a_CFLAGS) later.  Please note that the
nodist_*SOURCES mean that the .c files are not put in the tarball with
'make dist'.  If you prefer to have them distributed, so that, say, your
users don't need to have proc installed (I don't know if its output is
system-dependent or not), then you should omit the nodist_ prefix.

> These commands allow to create a static library from Pro*C files. I have now
> to link the library to create the executables using it.

Like:

bin_PROGRAMS = foo bar
foo_LDADD = libcomp.a
bar_LDADD = libcomp.a

Cheers,
Ralf

Re: Cross-compile tar-1.13

[Ralf Wildenhues]

Hello Steven,

* Steven Woody wrote on Sat, Aug 30, 2008 at 05:10:06PM CEST:
> 
> For some reasons I need to cross-compile a tar-1.13, the target is ARM
> and the build host is i686-pc-linux-gnu.  The tar-1.13's source come
> with a configure, that seems generated from a very old version of
> automake.  For recent automake version, I have success experience to
> do cross-compiling, that is, specify a '--host=arm-linux' when running
> the 'configure' script.  But for the tar-1.13's configure script, I
> failed to do it.  I tried the following method:
> 
> 1,  configure --host=arm-linux
> 2,  configure --target=arm-linux
> 3,  configure --host=arm-linux --build=i686-pc-linux-gnu
> 
> but all failed:  the 'configure' script did not try to find
> arm-linux-gcc, it still using gcc as compiler.  So I think, I did not
> active the cross-compiling in the script.

You did not mention which Autoconf version this tar's configure script
was created with.  It should be mentioned near the head of the script
somewhere.

Please try
   ./configure arm-linux

which was IIRC the way to do it with Autoconf 2.13.

Hope that helps.

Cheers,
Ralf

Re: how to install data directories

[Ralf Wildenhues]

Hello Matej, Remco,

First off, please do not top-post, and do not full-quote the messages
you reply to, unless you address each of the quoted bits.  Otherwise,
you will have a hard time getting useful comments on this list.  Thanks.

* Matej Tyc wrote on Sat, Aug 30, 2008 at 03:04:58PM CEST:
> On Fri, 2008-08-29 at 18:17 +0200, Remco Bras wrote:
> > you could do something like this in Makefile.am:
> > 
> > dirs = some_data_dir some_other_data_dir
> > install-data-local:
> > for d in $(dirs); hing. \
> >   do\
> > cp -Rv $d $(datadir)\
> >   done
> > 
> > Would this solution be acceptable?

Not really.  First off, there is an extra 'hing.' coming from somewhere,
that will cause a syntax error.  Likewise the missing semicolon after
the cp command.  Second, it is not portable to pass the option -v to cp.
Then, the rule is not $(DESTDIR) proof.  Next, the rule does not ensure
that $(DESTDIR)$(datadir) exists before files are copied to it.  The
rule fails to fail when, say, the first cp invocation fails.  The rule
will fail if $(DESTDIR)$(datadir) contains white space.

As a matter of following GNU Coding Standards, the rule should be using
the `install' program, preferably as $(INSTALL_DATA), rather than plain
cp.  Also, it should be prepended with a command line containing
@$(NORMAL_INSTALL)

but that's one of the finer points of the GCS.

As Matej already remarked, the rule also lacks an accompanying uninstall
rule.

For what it's worth, the Automake way of doing this would be to list
every file in the Makefile.am (or maybe in an included, generated
Makefile.am snippet).  That way you ensure to not install any CVS files
or directories, backup files, other unwanted stuff.  (There is more
reasoning about this in the manual.)

> 1. What about `make uninstall`? Will the files be removed if they were
> installed in that way?

Exactly.  A 'make distcheck' would have told you this quite early.

> 2. This requires the user to write shell scripts in Makefile.am, which
> is, if I understand this correctly, a file mainly for declaration of
> intentions that should be as readable as possible. I think that it is
> highly inapropriate to write a low-level script to achieve a really
> trivial and common task.

This is a common misconception.  The contents of Makefile.am get copied,
almost verbatim, into the Makefile generated from it.  That means, for
everything where there exists no Automake-provided way of doing things,
you typically write rules for yourself, just as you would in a plain
Makefile.

> And a second one: What about a wiki? I relly miss that! Manuals are
> good, but solutions of problems like this one should be summarized in
> some centralized place so others could learn from it and maintain it as
> autotools evolve...

You keep going back to this point.  If anything, this thread has been an
argument against a wiki.  Come back with a couple of solutions that work
and are portable and usable for more than one issue, then we'll gladly
put them in the FAQ section in the manual.  Show that you can create
good solutions yourself without review, and you'll have a case for a
wiki.  Note that I don't count myself in that latter category.

Hope that helps.

Cheers,
Ralf

Re: libtool (1.5.26) with mingw/msys and eclipse problem

[Ralf Wildenhues]

* Joost Kraaijeveld wrote on Thu, Aug 28, 2008 at 11:13:01PM CEST:
> On Thu, 2008-08-28 at 20:33 +0200, Ralf Wildenhues wrote:
> > 
> > What is it that Eclipse does differently from ../configure && make?
> As far as I can determine: nothing. The only thing I can come up with is
> that Eclipse calls "make" using *cmd.exe* instead of sh.exe (the latter
> being used in MSYS), which of course returns Windows paths and not
> MSYS/unixlike paths..

Can you influence Eclipse's choice of shell to use?

> But the actual error is caused by the following path changes :
[...]
> The non-working Eclipse file:
> 
> dependency_libs=' D:\workspace/Danu/mingw/library/DanuBase/libdanubase.la 
> -lpthread'
> [snip]
> relink_command="(cd D:\\workspace/Danu/mingw/library/DanuStream; /bin/sh 
> ../libtool  --tag=CXX --mode=relink g++ -I/d/boost/include -g -Wall -Wextra 
> -Wundef -Wshadow -Wconversion -Wmissing-declarations -no-undefined -o 
> libdanustream.la -rpath /usr/local/lib libdanustream_la-BaseStream.lo 
> libdanustream_la-ByteStream.lo libdanustream_la-DllMain.lo 
> libdanustream_la-FileStream.lo libdanustream_la-StreamableObject.lo 
> libdanustream_la-StreamableObjectCreator.lo 
> libdanustream_la-StreamableObjectFactory.lo 
> ../../library/DanuBase/libdanubase.la @inst_prefix_dir@) "
> 
> Notice the change from /d/ to d:\  in the first and /d/ to d:\\ in the
> second quoted line.
> 
> The error I get is saying something about D:workspace, so I assume that
> it is about the first line without the escaped \ in d:\workspace.

Please post the exact error (copy and paste), as well as the command you
issued that led to it, thanks.

Cheers,
Ralf

Re: Automake with Pro*C

[Ralf Wildenhues]

Hello Sebastien,

* Sebastien REYNES wrote on Tue, Aug 26, 2008 at 05:31:09PM CEST:
> 
> Is it possible to use automake tool with Pro*C ?

FWIW, I don't know Pro*C.  There is no special support for it in
Automake.  That doesn't mean you can't use it, though.  There is
some general information on using generated sources in the manual:



> How can I edit the
> Makefile.am to generate .c sources from .pc sources ?

Likely in the same way you'd write a plain Makefile rule for doing this.

PCCOMPILE = proc ...
.pc.c:
$(PCCOMPILE) ... -o $@ $<

> bin_PROGRAMS = myprog
> myprog_SOURCES = myprog.c myprog.pc
> my_prog_LDADD=$ORACLE_HOME/precomp/lib/libpgp.a# library of the 
> precompilator pro*C

> Do you know where could I find any example(s) using automake with
> precompilation from Pro*C files ?

No sorry.  You can probably find out in the Pro*C documentation how to
invoke the precompiler.

Hope that helps.

Cheers,
Ralf

Re: [automake] Dependency question with _LDADD

[Ralf Wildenhues]

* Braden McDaniel wrote on Wed, Aug 27, 2008 at 08:45:56PM CEST:
> Ralf Wildenhues wrote:
>> * Braden McDaniel wrote on Wed, Aug 27, 2008 at 08:48:45AM CEST:
>>> ... which brings up a question I have: Why doesn't AC_CONFIG_MACRO_DIR
>>> eliminate the need for setting ACLOCAL_AMFLAGS as such?
>>
>> Hmm.  You typically have one AC_CONFIG_MACRO_DIR where for example
>> 'aclocal --install' or 'libtoolize --install' will dump macro files.
>> However, you can have several places in the tree where you need to
>> pick up macro files from, with -I paths.
>
> Fair enough; but most don't have more than one such directory. As a  
> result, having to point the autotools at this directory in more than one  
> place feels redundant.

Yes, agreed.  As does the fact that adding new Makefile.am files
requires adding an AC_CONFIG_FILES stanza plus a SUBDIRS entry
(which is what allows to mix automake-generated Makefile.in's with
others; and creative subdirectory orderings).

> Is there a reason not to give aclocal invocations a -I flag for the  
> AC_CONFIG_MACRO_DIR? ACLOCAL_AMFLAGS could complement this.

Not sure.  Since this typically is a one-time operation, and not a
hassle that you have to take care of regularly, I'm rather cautious
to add an automatism here, in case someone ends up having a good use
case for AC_CONFIG_MACRO_DIR without ACLOCAL_AMFLAGS pointing there.

Cheers,
Ralf

Re: EXTRA_PROGRAMS not automatically cleaned

[Ralf Wildenhues]

Hi Reuben,

* Reuben Thomas wrote on Wed, Aug 27, 2008 at 10:09:27PM CEST:
> I just noticed that programs listed in EXTRA_PROGRAMS in Makefile.am are 
> not automatically added to any clean target, so make distcheck fails. I 
> can of course add $(EXTRA_PROGRAMS) to CLEANFILES, but it seems odd as I 
> don't have to do that for other programs, e.g. bin_PROGRAMS or 
> check_PROGRAMS.

Hmm.  The rule is that those things get removed by 'make clean' that get
built by 'make all'.  EXTRA_PROGRAMS aren't built by default, whereas
bin_PROGRAMS are.  check_PROGRAMS are only built by 'make check', but
since that typically contains files that depend upon files created by
'all', I think it's reasonable to remove both upon 'clean'.

Hmm, I'm not sure but I can imagine a situation where the Makefile.am
author sometimes wants a program in EXTRA_PROGRAMS to be built and
removed upon 'all' and 'clean', and sometimes wants neither to happen;
e.g., because building the program is very expensive.

Hope that helps.

Cheers,
Ralf

Re: libtool (1.5.26) with mingw/msys and eclipse problem

[Ralf Wildenhues]

Hello Joost,

* Joost Kraaijeveld wrote on Thu, Aug 28, 2008 at 04:02:58PM CEST:
> 
> I have a large Makefile project that uses autotools for configuration.
> If I run "../configure" and "make" from the MSYS command prompt (rxvt)
> everything configures an compiles OK. 
> 
> However, if I use Eclipse to compile using exactly the same Makefiles, I
> get an error at link-time: for some reason libtool (1.5.26) decides to
> rewrite it's files (the asci stub files that point to the actual
> library) and forgets that paths in Windows and MSYS work differently in
> the process.
> 
> Is it possible to make libtool use the correct paths? 

What is it that Eclipse does differently from ../configure && make?
How about fixing that?

As far as I understand, this is not a problem of autotools/libtool,
but one of the program using them.  If you think otherwise, then I
would like to see more details.

Cheers,
Ralf

Re: [automake] Dependency question with _LDADD

[Ralf Wildenhues]

Hi Braden,

* Braden McDaniel wrote on Wed, Aug 27, 2008 at 08:48:45AM CEST:
> On Wed, 2008-08-27 at 07:41 +0200, Ralf Wildenhues wrote:
> > * Michel Briand wrote on Wed, Aug 27, 2008 at 03:19:24AM CEST:
> > > Ralf Wildenhues <[EMAIL PROTECTED]> - Tue, 26 Aug 2008 17:43:13 +0200
> > > >Why '-I config -I m4'?  AFAICS you do not use AC_CONFIG_MACRO_DIR([m4])
> > > >in configure.ac.  I'd use that, and drop '-I config'.
> > > 
> > > I do not use the macro you mention.
> > 
> > Please do, though.  When you do, please also add
> >   ACLOCAL_AMFLAGS = -I m4
> > 
> > to the toplevel Makefile.am.
> 
> ... which brings up a question I have: Why doesn't AC_CONFIG_MACRO_DIR
> eliminate the need for setting ACLOCAL_AMFLAGS as such?

Hmm.  You typically have one AC_CONFIG_MACRO_DIR where for example
'aclocal --install' or 'libtoolize --install' will dump macro files.
However, you can have several places in the tree where you need to
pick up macro files from, with -I paths.

Cheers,
Ralf

Re: [automake] Dependency question with _LDADD

[Ralf Wildenhues]

* Michel Briand wrote on Wed, Aug 27, 2008 at 03:19:24AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> - Tue, 26 Aug 2008 17:43:13 +0200
> >* Michel Briand wrote on Tue, Aug 26, 2008 at 05:09:34PM CEST:
> >>
> >> What do you think of my example ? Is it useful for other people
> >> to learn autotools ?
> >
> >I don't know.  Typically, I'm bad at guessing what beginners need in
> >order to learn.
> 
> Writing this complete example was for me a wonderful learning
> experience. I hope that this template could help the maximum of new
> users of GNU build system.

Well, do you think it's the finished template or the fact that you've
written it from scratch, that helped you learn better?  If the latter,
then other new users won't benefit as much from reading the template.

> >> autoreconf --force --install -I config -I m4
> >
> >Why '-I config -I m4'?  AFAICS you do not use AC_CONFIG_MACRO_DIR([m4])
> >in configure.ac.  I'd use that, and drop '-I config'.
> >
> 
> I do not use the macro you mention.

Please do, though.  When you do, please also add
  ACLOCAL_AMFLAGS = -I m4

to the toplevel Makefile.am.

> So I can drop '-I m4' and have this
> command:
> 
> autoreconf --force --install -I config
> 
> But, I also use AC_CONFIG_AUX_DIR([config]). So may I cut '-I config'
> and have finally ?:
> 
> autoreconf --force --install

Yes.

> >> # Version: simpliest way to implement versioning
> >> PROGRAM_VERSION=`cat PROGRAM_VERSION`
> >> AC_SUBST(PROGRAM_VERSION)
> >> LIBRARY_VERSION=`cat LIBRARY_VERSION`
> >> AC_SUBST(LIBRARY_VERSION)
> >
> >These statements cause config.status output to be dependent upon the
> >files PROGRAM_VERSION and LIBRARY_VERSION.  Thus, I would add
> >  CONFIG_STATUS_DEPENDENCIES='$(top_srcdir)/PROGRAM_VERSION 
> > $(top_srcdir)/LIBRARY_VERSION'
> >  AC_SUBST([CONFIG_STATUS_DEPENDENCIES])
> >
> >so that configure is automatically rerun when those files change.
> >
> 
> Thank you for this tip ! But know I see I must instruct automake to
> rebuild the library if the file LIBRARY_VERSION changes. And the
> program is the file PROGRAM_VERSION changes...
> 
> Should I use the <>_DEPENDENCIES variable ?

Yes, I think I addressed that later in the message.

> >> # C++ is not used, so related checks are not needed
> >> m4_defun([_LT_AC_LANG_CXX_CONFIG], [:])
> >> # Same for Fortran
> >> m4_defun([_LT_AC_LANG_F77_CONFIG], [:])
> >
> >The above four lines are obsolete once you update your Libtool to a
> >version newer than 2.1.  So why even include them in a beginners'
> >document?
> 
> Debian (stable, testing, unstable) ships with libtool 1.5. So I have to
> take care.

Let's just hope lenny isn't far away any more.

> I can't use libtool 2.x now but I've seen in the
> documentation many improvements like this :))). I hope this is
> equivalent to the new useful LT_INIT and LT_LANG declarations.

AC_PROG_LIBTOOL is mostly equivalent to LT_INIT.  You won't need to use
LT_LANG yourself in most setups.  (Libtool will infer the needed
languages from the AC_PROG_{CC,CXX,FC,F77} and AM_PROG_GCJ macros you
use.

> >> AM_CPPFLAGS = -DLIBRARY_VERSION=\"$(LIBRARY_VERSION)\"
> >
> >Why not put
> >  AC_DEFINE([LIBRARY_VERSION], ...)
> >
> >in configure.ac, so you don't need the above?  Of course you may want to
> >use a less generic name, e.g. TRAINING_LIBRARY_VERSION.

> OK. That's a lot more concise. But having done this:
> 
> # Step 1: extract version number from a source file
> TRAINING_PROGRAM_VERSION=`cat PROGRAM_VERSION`
> # Step 2: export this variable to Makefile
> AC_SUBST(TRAINING_PROGRAM_VERSION)
> # Step 3: export this variable as a C define (config.h)
> AC_DEFINE([TRAINING_PROGRAM_VERSION], TRAINING_PROGRAM_VERSION, Program's 
> version)
> 
> I've seen that this don't work. And I've changed AC_DEFINE by
> AC_DEFINE_UNQUOTED. And it works like this:
> 
> AC_DEFINE_UNQUOTED([TRAINING_PROGRAM_VERSION], "${TRAINING_PROGRAM_VERSION}", 
> [Program's version])

Ah, sorry for mentioning AC_DEFINE, of course AC_DEFINE_UNQUOTED is
right.

> But I suspect there is some redundancy there in. Is this the better way
> to do that ?

I don't see one right away.

[ prog_DEPENDENCIES... ]
> >FWIW, you could actually add ../../LIBRARY_VERSION to this variable.
> 
> Yes, it works well too. I'll have all my dependencies handled that way.
> 
> But working a little with it, I have one remark: 
> 
> si

Re: [automake] Dependency question with _LDADD

[Ralf Wildenhues]

> * Michel Briand wrote on Tue, Aug 26, 2008 at 05:09:34PM CEST:
> > libtraining_la_LDFLAGS = -version-info ${LIBRARY_VERSION}

You could add -no-undefined here, so that your library will also be
built shared on w32 systems.  Of course, that requires that your library
doesn't use undefined symbols.

Cheers,
Ralf

Re: [automake] Dependency question with _LDADD

[Ralf Wildenhues]

Hello Michel,

can we limit followups to the automake list only, please?

* Michel Briand wrote on Tue, Aug 26, 2008 at 05:09:34PM CEST:
> 
> as an exercise I decided to learn the maximum about automake and
> libtool, and write a complete example.

Thanks.  Some nits below.

> What do you think of my example ? Is it useful for other people
> to learn autotools ?

I don't know.  Typically, I'm bad at guessing what beginners need in
order to learn.

> I implemented library & program versioning. Basically.

OK.

> I also modified the program's Makefile.am to not rebuild the program
> when the library was just rebuilt.

I don't think showing that to a beginner is a good idea.  It's certainly
safer to let the program be rebuilt when the library changes.  But see
below for more specific remarks.

Here's a bit of review:

> ::
> autogen.sh
> ::
> autoreconf --force --install -I config -I m4

Why '-I config -I m4'?  AFAICS you do not use AC_CONFIG_MACRO_DIR([m4])
in configure.ac.  I'd use that, and drop '-I config'.

> ::
> configure.ac
> ::
> AC_INIT([autotraining], [1.0], [EMAIL PROTECTED])
> AC_CONFIG_AUX_DIR(config)

If you aim at beginners, teach them the right manners by consistently
using correct m4 quotation:

  AC_CONFIG_AUX_DIR([config])

> AM_INIT_AUTOMAKE
>
> # Version: simpliest way to implement versioning
> PROGRAM_VERSION=`cat PROGRAM_VERSION`
> AC_SUBST(PROGRAM_VERSION)
> LIBRARY_VERSION=`cat LIBRARY_VERSION`
> AC_SUBST(LIBRARY_VERSION)

These statements cause config.status output to be dependent upon the
files PROGRAM_VERSION and LIBRARY_VERSION.  Thus, I would add
  CONFIG_STATUS_DEPENDENCIES='$(top_srcdir)/PROGRAM_VERSION 
$(top_srcdir)/LIBRARY_VERSION'
  AC_SUBST([CONFIG_STATUS_DEPENDENCIES])

so that configure is automatically rerun when those files change.

> # C++ is not used, so related checks are not needed
> m4_defun([_LT_AC_LANG_CXX_CONFIG], [:])
> # Same for Fortran
> m4_defun([_LT_AC_LANG_F77_CONFIG], [:])

The above four lines are obsolete once you update your Libtool to a
version newer than 2.1.  So why even include them in a beginners'
document?

> AM_PROG_LIBTOOL

This macro has been spelled AC_PROG_LIBTOOL for years, and LT_INIT since
Libtool 2.2.  Might want to at least use the AC_* form for clarity,
otherwise your adept reader might search needlessly.

> ::
> src/lib/Makefile.am
> ::
> # Library: libtraining
> # Generates its own pkg-config definition file
> 
> AM_CPPFLAGS = -DLIBRARY_VERSION=\"$(LIBRARY_VERSION)\"

Why not put
  AC_DEFINE([LIBRARY_VERSION], ...)

in configure.ac, so you don't need the above?  Of course you may want to
use a less generic name, e.g. TRAINING_LIBRARY_VERSION.

Similar applies to -DPROGRAM_VERSION in src/bin/Makefile.am.

> pkgconfigdir = $(libdir)/pkgconfig
> pkgconfig_DATA = libtraining.pc
> 
> lib_LTLIBRARIES = libtraining.la

> libtraining_la_includedir = $(includedir)
> libtraining_la_include_HEADERS = libtraining.h

For what it's worth, I'd replace the two lines above with this one line
only:
  include_HEADERS = libtraining.h

> libtraining_la_SOURCES = training.c

Since you're making an example package, how about adding an uninstalled
header here:
  libtraining_la_SOURCES = training.c internal_header.h

so that users know where to add that?

> libtraining_la_LDFLAGS = -version-info ${LIBRARY_VERSION}


> ::
> src/bin/Makefile.am
> ::
> # Main program: training
> # Uses libtraining in ../lib
> 
> LIBTRAINING_DIR=../lib
> 
> AM_CPPFLAGS = -DPROGRAM_VERSION=\"$(PROGRAM_VERSION)\" -I$(LIBTRAINING_DIR)
> AM_LDFLAGS = -L$(LIBTRAINING_DIR)

Please drop this line.

> bin_PROGRAMS = training
> training_SOURCES = training.c
> training_LDADD = -ltraining

This last line is wrong, too.  The two *have* to be replaced with this
one line:
  training_LDADD = ../lib/libtraining.la

Why?  Because otherwise, paths to the uninstalled $builddir/src/lib may
end up in the installed binary on some systems.  That can be a security
issue.  If you want to work around the rebuilding issue, then *please*
guard it with a big fat comment that this isn't for the faint of the
heart, and should not be done typically.  And then do it like this:
  # Explicitly override the dependency on any libraries, to hack away
  # automatic rebuilds.  Done because the author knows better than to
  # change the library incompatibly:
  training_DEPENDENCIES =

FWIW, you could actually add ../../LIBRARY_VERSION to this variable.

I should note that when I encounter newbies reporting bugs against
autotools, which turn out to have broken builds due to this setting
of yours, I will gladly send them to you.

Hope that helps.

Cheers,
Ralf

Re: Problems with library on macos X

[Ralf Wildenhues]

Hello Daniel,

* Daniel Luis dos Santos wrote on Fri, Aug 22, 2008 at 12:34:23AM CEST:
> 
> I am trying to build a library on a leopard machine with autoconf 2.61 and
> automake 10.1 from mac ports. The generated makefile has no object files and
> then the ar command fails with : 
> 
> ar cru libliquidsurfaces.a  
> ar: no archive members specified
> usage:  ar -d [-TLsv] archive file ...

Yep, unfortunately passing no files to 'ar cru $lib' is not portable,
besides the fact that POSIX requires you to pass at least one file.
You can add a dummy object with source containing
  static int foo;

> lib_LIBRARIES = libliquidsurfaces.a
> libliquidsurfaces_a_SOURCES = LiquidSurfaces.cp LiquidSurfacesPriv.h
> #libliquidsurfaces_a_LIBADD = LiquidSurfaces.o
> include_HEADERS = LiquidSurfaces.h
> 
> I have included the .o in the commented _LIBADD but probably that won't work
> because no public symbols are put in the library file.

I don't think anybody minds if there are no public symbols (but my
memory is a bit vague here, might want to search the list archives
on this).

> How can I tell in the makefile what are the names of the object files,
> instead of being derived from the Sources ?

Object file names generally are an internal Automake detail, which you
should have no knowledge of.  (They might be renamed in the presence of
per-target compile flags.)  Just listing sources in lib*_SOURCES should
get the objects compiled from those sources into the archive.

Hope that helps.

Cheers,
Ralf

Re: Buglet on http://sources.redhat.com/automake/

[Ralf Wildenhues]

Hi Magnus,

* Magnus Fromreide wrote on Wed, Aug 20, 2008 at 11:01:57PM CEST:
> Under "Availability" it says
[...]
> The problem is that ftp.gnu.org points to
> ftp://ftp.gnu.org/gnu/automake/automake-1.10.tar.gz and I think it would
> be good if it could point to 1.10.1.

Fixed, thanks for the report!

Cheers,
Ralf

Re: [PPL-devel] Configure substitutions are not allowed in _SOURCES variables

[Ralf Wildenhues]

* Roberto Bagnara wrote on Thu, Aug 21, 2008 at 08:00:04PM CEST:
> Ralf Wildenhues wrote:
>>
>> Are you saying that you generate Makefile.am (or an include snippet
>> for it) automatically?

> no.  In the previous version we generated automatically the individual
> C++ sources, including one that #included all the others.  The list
> of C++ sources is only known at configure time: at that time the
> sources are generated.

Well, as long as the list of possible source can be enumerated, you can
use EXTRA_*_SOURCES to list them.

>> If not, why not, if yes, what is the problem
>> with maintaining consistency with a script?  Ideally, you generate
>> both the files and the makefile.am snippet from the same script.
>
> Can I generated the Makefile.am at configure time?

No.

> Notice that
> the list of domains is really unbounded: the PPL supports constructions
> on domains like products and powersets.  So the user can ask
> for a product of a powerset of a product of ...
> We really cannot anticipate all the possibilities.

That's a problem.

There *may* be a workaround.  Let's rather call it ugliest hack ever.
It *requires* that you don't use per-target flags.  It does not provide
dependency tracking for the generated files.

> I am halfway through it.  I thought I had found a workaround,
> but there are still problems.  What I have at the moment is
> something that suffers from the problem outlined above and,
> in addition, does not work:
[...]
> # @required_instantiations_prolog_cxx_objects@ contains
> # the list of the .lo file corresponding to the .cc files
> # above.  If I do `make libppl_swiprolog.la' I get
> # the error that the (inexistent) .lo files are invalid
> # Libtool files.  Bot if I do, e.g.,
> # `make pl_prolog_Polyhedron.lo' the right thing happens.
> # I wonder why `make libppl_swiprolog.la' does not make
> # all the required .lo files.

Yep.  Your approach is essentially the hack I had in mind.
Put the added objects in libppl_swiprolog_la_DEPENDENCIES,
too, then things will work.  Of course then you have to
put everything else manually in that DEPENDENCIES variable,
too (which automake would otherwise do).

Cheers,
Ralf

Re: Configure substitutions are not allowed in _SOURCES variables

[Ralf Wildenhues]

Hello Roberto,

* Roberto Bagnara wrote on Thu, Aug 21, 2008 at 12:55:25PM CEST:
>
[ ... lots of sources, conditional and all ... ]

> Using the solution outlined in the Automake manual
> (i.e., using conditionals) would cause us to write enormous
> Makefile.am files which would be a maintenance nightmare.
> That is, now everything is automated; if we use a long
> chain of conditionals we would have to maintain consistency
> by hand.

Are you saying that you generate Makefile.am (or an include snippet
for it) automatically?  If not, why not, if yes, what is the problem
with maintaining consistency with a script?  Ideally, you generate
both the files and the makefile.am snippet from the same script.

Do you already do the splitup in CVS?  I cannot see it there
(I just got HEAD from :pserver:[EMAIL PROTECTED]:/cvs/ppl).

Cheers,
Ralf

Re: Putting files in AC_CONFIG_AUX_DIR, `..'.

[Ralf Wildenhues]

Hello Joost,

* Joost Kraaijeveld wrote on Fri, Aug 15, 2008 at 02:54:25PM CEST:
> 
> I get the message "Putting files in AC_CONFIG_AUX_DIR, `..'." from
> libtoolize.
> 
> Can anyone tell me what this means, if it is harmful and,if needed, what
> I can do about it?

It means libtoolize thinks that the place for your auxiliary build files
(like install-sh, config.guess, config.sub, ltmain.sh, etc.) is in
directory `..', i.e., one above the one where libtoolize is called from.
If that matches your package's setup, then all is well, and you need not
do anything about it.  You can control the directory with the
AC_CONFIG_AUX_DIR macro called in configure.ac.

Hope that helps.

Cheers,
Ralf

Re: Warn: non-POSIX variable name

[Ralf Wildenhues]

* Peter Johansson wrote on Wed, Aug 20, 2008 at 05:23:10AM CEST:
> Steven Woody wrote:
>> 2. What's the difference between @varname@ and $(varname) in a
>> Makefile.am? I noted you use many @@
>>   
> I think the difference is that for example @builddir@ is substituted to  
> '.' when the Makefile is created from Makefile.in, so for instance:
[...]

Correct.

> but since $(builddir) is set to `.', I dont think it matters if having  
> @xxx@ or $(xxx) in this case.

It doesn't matter for the contents of this rule, as 'make' sees it.
However, in general, @substitutions@ cannot be interpreted by automake,
while $(macros) typically can.  Most of the time you want automake to
see as much of it as possible, so as a guide line, prefer $(macros) in
Makefile.am.

Cheers,
Ralf

Re: [automake] Dependency question with _LDADD

[Ralf Wildenhues]

Hello Michel,

* Michel Briand wrote on Tue, Aug 19, 2008 at 05:03:29PM CEST:
> 
> Referring to GNU Automake manual §8.1.2, I'm using the _LDADD
> variable in my Makfile.am to link it with my library built in the same
> package (but in a different directory).
> 
> But every time I rebuild the library (without having changed any .h) the
> program is relinked.

Which is as it should be: the program depends upon the library.

Are you referring to a static or shared library BTW?  With static
libraries, it is pretty easy to see why the program needs updating:
the code of the archive ends up in the program.  With shared libraries,
it is not strictly necessary to relink the program if the library has
undergone only backward-compatible changes.  But automake cannot know
that, so the safe thing to do is to relink.  Besides, even with
compatible changes you want your program to pick up new versioned
symbols (if used) and the like.

> I'd like to have a Makefile.am that will not generated relinking of my
> program once it has been linked one time.

Why?

You can probably achieve what you desire by setting
_DEPENDENCIES manually.  Look in the current Makefile.in for how
automake sets it, and put an adjusted setting in Makefile.am.

Hope that helps.

Cheers,
Ralf

Re: Warn: non-POSIX variable name

[Ralf Wildenhues]

Hello,

* Brian Dessent wrote on Tue, Aug 19, 2008 at 04:51:42AM CEST:
> Steven Woody wrote:
> > 
> > rmeterd_CXXFLAGS = \
> > -D'SVN_REV="$(shell ../../svnrev-sh)"' \
> > -D'SVN_DATE="$(shell ../../svndate-sh)"'

> > What's the correct way to do this without warning? Thanks.
> 
> Are you asking how to do this in a way that's not GNU make specific, or
> are you asking how to make automake not warn about it?  For the latter,
> add -Wno-portability to your automake options (globally in
> AM_INIT_AUTOMAKE or per-Makefile in AUTOMAKE_OPTIONS.)  For the former,
> run the script at configure-time rather than at make-time and AC_SUBST
> the resulting value.

Of course one could also simply use plain old backquote command
substitution: -D"SVN_REV=`../../svnrev-sh)`"
but that would run the scripts each time those flags were used
anywhere, which would be pretty expensive.  Or use
  rmeterd_CXXFLAGS := -D"SVN_REV=`../../svnrev-sh)`" ...

that would be less expensive, still GNU make-specific (due to the ':='),
but probably fixable in 5 seconds by a user that were eager to cope with
another make.

Cheers,
Ralf

Re: best practice advice, use of a custom local-clean target

[Ralf Wildenhues]

Hi Noah,

* Noah Slater wrote on Mon, Aug 18, 2008 at 01:19:46PM CEST:
>  * Why do I need to create my own target to clean up the Makefile.in files and
>other sundry left overs?

Because the functionality is notoriously difficult to implement nicely
in autotools itself, so that it works under all circumstances.  Benoit
worked on it last year, we've never finished it.

> Should Automake not ideally clean this up for me?

Yes, I guess it should.

>  * Should I be using $(top_srcdir) in those rules or is it safe to assume that
>the target is being run from the top source directory?

You should be using $(top_srcdir).  Better even if you
  cd "$(top_srcdir)" && find . -name ...

because that way you run into command line length issues later.

HTH. Cheers,
Ralf

Re: AM Conditional for SUBDIRS

[Ralf Wildenhues]

Hello Vikram,

* Vikram Ambrose wrote on Thu, Aug 07, 2008 at 10:49:58PM CEST:
> Monty Taylor wrote:
>> Vikram Ambrose wrote:
>>>
>>> SUBDIRS = pkgA pkgB $(extra_pkgs)
>>>
>>> extra_pkgs =
>>> if BUILD_pkgC
>>>   extra_pkgs += pkgC
>>> endif
>>>
>>> Both of which work, for make; make install; make clean; but when i try
>>> to make dist or make distclean, they fail. I do a test in configure.ac
>>> to conditional set AC_CONFIG_FILES([pkgc/Makefile])
>>>
>>> How do I do this properly?

Don't conditionally set AC_CONFIG_FILES([pkgc/Makefile]): if your user
wants to be able to conditionally build pkgc, then you need to
unconditionally distribute it, and for the dist rules you need that
Makefile.


has more information about different possible setups for conditional
building.

Hope that helps.

Cheers,
Ralf

Re: Nesting and final linking ?

[Ralf Wildenhues]

Hi Nick,

* nickthefarrow wrote on Thu, Aug 07, 2008 at 02:27:03PM CEST:
> Ralf,
> 
> Spot on :)

I wish all reports were this straightforward.  ;-)

> bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2 --tag=CXX  -o

This is weird: why is there a --tag=CXX so late in the game?
It should appear before --mode.  Did you perchance put it manually in
Makefile.am?  If yes, then you need to move it to a *_LIBTOOLFLAGS
variable or override the LIBTOOL variable.  But I'd advise against
either unless you are specifically working around something.

If you would like to get libtool to use the C++ compiler (and settings)
for linking, then the end of this manual node contains a hint:
.

> libwhite.la -rpath /usr/local/lib  src/utils/libutils.la
> src/common/libcommon.la src/libsrc.la src/containers/libcontainers.la
> src/FileIO/libfileio.la src/network/libnetwork.la src/parsers/libparsers.la
> src/servers/libservers.la src/stacks/libstacks.la
> 
> This bit looks fine, all the sub libs components are mentioned here (above)

> gcc -shared  -Wl,--whole-archive src/common/.libs/libcommon.a
> src/.libs/libsrc.a src/containers/.libs/libcontainers.a
> -Wl,--no-whole-archive  -Wl,--rpath -Wl,/home/nick/libwhite/src/utils/.libs
> -Wl,--rpath -Wl,/home/nick/libwhite/src/FileIO/.libs -Wl,--rpath
> -Wl,/home/nick/libwhite/src/network/.libs -Wl,--rpath
> -Wl,/home/nick/libwhite/src/parsers/.libs -Wl,--rpath
> -Wl,/home/nick/libwhite/src/servers/.libs -Wl,--rpath
> -Wl,/home/nick/libwhite/src/stacks/.libs -Wl,--rpath -Wl,/usr/local/lib
> src/utils/.libs/libutils.so src/FileIO/.libs/libfileio.so
> src/network/.libs/libnetwork.so src/parsers/.libs/libparsers.so
> src/servers/.libs/libservers.so src/stacks/.libs/libstacks.so  -Wl,-soname
> -Wl,libwhite.so.0 -o .libs/libwhite.so.0.0.0

This bit of output indicates that these are convenience archives (i.e.,
noinst_LTLIBRARIES):
  src/common/libcommon.la src/libsrc.la src/containers/libcontainers.la

while these are real shared, to-be-installed, libraries (i.e.,
lib_LTLIBRARIES or similar):
  src/utils/libutils.la src/FileIO/libfileio.la
  src/network/libnetwork.la src/parsers/libparsers.la
  src/servers/libservers.la src/stacks/libstacks.la

That means, that the first three will end up as a whole being part of
libwhite, while the last six will be independent entities, upon which
libwhite will depend.  However, libwhite will not contain any code of
them directly.  This makes sense: that way, each function is contained
at most once in the set of installed libraries.

If that is not what you wanted, then you should consider making the
other libraries into convenience archives.

If however that is what you wanted, then I suggest using a bit more
specific names for the libraries.  libutils is quite generic and likely
to interfere with somebody else who had the same naming idea.  Keep in
mind that every library you install effectively lives in a global
namespace, one for the library name (and soname), and also their
functions live in a global namespace, and hopefully are part of a
defined and stable API.  (Consider hiding functions you don't want to be
used outside the library; at least for systems that provide hiding.)

> This again looks ok (above)

> ar cru .libs/libwhite.a  
> .libs/libwhite.lax/libcommon.a/libcommon_la-packetbuffer.o
[...]
> .libs/libwhite.lax/libcommon.a/libcommon_la-ITokenizer.o 
> .libs/libwhite.lax/libsrc.a/libsrc_la-IDebug.o
> .libs/libwhite.lax/libsrc.a/libsrc_la-IObject.o 
> .libs/libwhite.lax/libcontainers.a/libcontainers_la-IFileTree.o
> .libs/libwhite.lax/libcontainers.a/libcontainers_la-IVariant.o
> .libs/libwhite.lax/libcontainers.a/libcontainers_la-IMIMETypes.o

> The final library only consists of libsrc, libcommon, libcontainers and not
> the others libstacks etc, and it looks like libcommon is partial, it should
> consist of 39 objects I dont really know what script its running here
> (ltmain.sh?) or why is missing the rest.

The script that creates libraries is 'libtool', it is created from some
variables set by configure, combined with the ltmain.sh file.

> The only thing that comes to mind is running out of environment space?

That would be a bit surprising, your example doesn't look particularly
big (there are libraries consisting of dozens of convenience archives,
and comprising hundreds of objects), and libtool really aims at working
around all those system limitations.

Since the part about the missing libs has already been addressed, the
only remaining bit is the missing objects from libcommon.  Can you post
the output of the following:

  make >/dev/null# this output is not interesting
  ./libtool --mode=clean rm -f src/common/libcommon.la libwhite.la
  make

Also, please post the output of
  ./libtool --tag=CXX --config

Thanks,
Ralf

Re: Nesting and final linking ?

[Ralf Wildenhues]

Hi Nick,

* nickthefarrow wrote on Thu, Aug 07, 2008 at 10:17:57AM CEST:
> 
> Making all in .
> make[2]: Entering directory `/home/nick/libwhite'
> make[2]: *** No rule to make target `src/common/libcommon.la', needed by 
> `libwhite.la'.  Stop.
> make[2]: Leaving directory `/home/nick/libwhite'
[...]
> my top level makefile.am is
> --
> SUBDIRS = . ./src/common/

This is the culprit.  By listing '.' early in SUBDIRS you are in effect
telling Automake to build things in the current Makefile first, and only
then go into the src/common sub directory.  Solution is to list '.' last
or not at all (in which it will default to being last).

BTW, please drop the leading './' from that name here, it may confuse
some non-GNU make IIRC (they typically don't treat 'file' and './file'
as identical).

> AC_CONFIG_SUBDIRS([src/common])
> AC_OUTPUT(Makefile src/common/Makefile)

FWIW, listing arguments in AC_OUTPUT is a bit old-fashioned.  The new
way would be:
  AC_CONFIG_FILES([Makefile src/common/Makefile])
  AC_OUTPUT

Also, there is some bug lingering here: when you list src/common in
AC_CONFIG_SUBDIRS, then you are effectively saying that there is another
configure script in the src/common directory.  If that is the case, then
it should also be the case that that configure script creates the
Makefile in that directory; but your AC_OUTPUT line tells the toplevel
configure script to create the Makefile.  If both configure scripts do
this (and you can be certain that they won't produce identical results),
then things will get confused pretty quickly.

If you don't need another configure script in src/common, you can simply
remove the AC_CONFIG_SUBDIRS line.

Hope that helps.

Cheers,
Ralf

Re: Nesting and final linking ?

[Ralf Wildenhues]

Hello Nich,

* nickthefarrow wrote on Tue, Aug 05, 2008 at 12:07:35PM CEST:
> 
> I have a project that I need to automake the build on, thats has several
> levels of directories. I automake and ./configure from the top level and a
> makefile.am in each sub directory. This correctly generates a make file for
> the entire nesting.
> 
> I'm aiming to make a single library out of this build [...]

Then what you typically do is create a convenience library in each of
the sub directories, and at the end merge them together.

--- sub/Makefile.am ---
noinst_LTLIBRARIES = libconv.la
libconv_la_SOURCES = ...

--- Makefile.am ---
lib_LTLIBRARIES = libmylib.la
libmylib_la_SOURCES =
## yes, the previous line can be empty
libmylib_la_LIBADD = sub/libconv.la sub2/libconv.la ...

> and the current
> problem I have is that the individual object files dont seem to be linked.
> This hardly surprising as to prevent link errors I have a -c (no link)
> option for each subdirectory.

Get rid of that -c.

Hope that helps.

Alternatively, you can look into nonrecursive make setups, and do
something like

--- Makefile.am ---
lib_LTLIBRARIES = libmylib.la
libmylib_la_SOURCES = sub/file1.c sub2/file3.c ...

Cheers,
Ralf

Re: compatibility problem AC_SUBST

[Ralf Wildenhues]

* Fritz Code wrote on Mon, Aug 04, 2008 at 09:57:28PM CEST:
> 
> configure.in:74: configure substitutions are not allowed in _SOURCES
> variables

Yes, Automake 1.9 is unfortunately incompatible to 1.4 in some ways.
(If all else fails, you could try to get old versions from the gnu.org
ftp server, Autoconf 2.13 and Automake 1.4p6 should fit I guess; but
I won't be able to help much further.)

> AC_SUBST(WIDGET)
> AC_SUBST(DEBUGGING)
> AC_SUBST(VIDBASE)
> AC_SUBST(DRIVER)
> AC_SUBST(VIDWRAP)
> AC_SUBST(INPUT)
> AC_SUBST(FORMATS)
> AC_SUBST(FONT)
> AC_SUBST(APPMGR)
> AC_SUBST(OS)
> AC_SUBST(VIDSUBDIRS)
> AC_SUBST(CURSES)
> 
> Well after doing some reserach I found out that AC_SUBST is used to declare
> a variable in all files of the project.

It is used to transport variables from configure to generated files like
Makefiles.

> If I comment some of the statements above I can run autogen, configure. But
> make cancels with many linker errors.

> Well is there any alternative to AC_SUBST ?

You could try to hard-code the settings of the above variables in the
Makefile.  Or convert Makefile.am to use Automake conditionals:



Hope that helps.

Cheers,
Ralf

Re: gnupload --help examples

[Ralf Wildenhues]

Hi Karl,

* Karl Berry wrote on Sat, Aug 02, 2008 at 02:54:03AM CEST:
> I find myself consistently bemused by the complex example in the --help
> message of gnupload.  I just want something I can cut and paste, and I
> never upload to multiple targets, and I doubt many other projects do,
> either.

Agreed.  I've pushed your patch.  Thanks!

Cheers,
Ralf

Re: include directory structure

[Ralf Wildenhues]

Hello Monty,

* Monty Taylor wrote on Fri, Aug 01, 2008 at 06:50:04AM CEST:
> I read through the docs and I think there may be no good way to do
> this... but I thought I'd ask.
[...]
> As far as I can tell, the only way to achieve that would be to place all
> of the headers in nobase_include_HEADERS in the root Makefile.am, or to
> try to jimmy with the value of ${includedir} in each subdir Makefile.am...

Well, first you say there may be no good way, then you can tell of only
one way, but finally you list two ways.  ;-)

> Am I right, or am I missing something...

You are right in that the two ways should work.  I may be missing the
reason for which you may not like them?

FWIW, you don't have to mangle includedir or pkgincludedir; you can
instead create derived names:

  fooincludedir = $(includedir)/drizzle
  fooinclude_HEADERS = ...
  barincludedir = ...
  barinclude_HEADERS = ...

and of course each of them can be used together with nodist_, nobase_
prefixes.  And you can define the derived dir names either
per-Makefile.am or globally as AC_SUBSTs in configure.ac.

Since your installed directory structure matches your source tree one,
using nobase_(pkg)?include_HEADERS from the top level seems like a good
idea.

Hope that helps.

Cheers,
Ralf

Re: How to pinpoint aclocal failure

[Ralf Wildenhues]

Hello,

* Yang Tse wrote on Wed, Jul 30, 2008 at 08:17:54PM CEST:
> 
> Since I'm not sure if this is actually an automake or autoconf issue,

It's not clear from the bug report.

aclocal endless loops are a pain to debug.  If you can go back to a
known-good version (of configure.ac and *.m4 files), you may be able to
bisect.  Otherwise I remember that there have been some issues in the
interaction of Libtool or Autoconf macros.  You may be able to find
clues when searching the mailing list archives for it.

Otherwise, can you make a tarball or VCS-repository available with which
the issue may be reproduced?

> Could some additional tracing be enabled even if we need to edit whatever ?

Yes, sometimes putting m4_traceon() or traceon() in strategic places can 
help (but don't complain about the sheer volume of output; there is
traceoff as well).

Hope that helps.

Cheers,
Ralf

Re: automake generates delete targets twice

[Ralf Wildenhues]

Hello Toralf,

* Toralf Förster wrote on Wed, Jul 30, 2008 at 09:26:10AM CEST:
> 
> regarding to https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2749 I'm
> wondering whether at UNIX systems automake could be improved to delete a 
> target
> only once.

Why?  (This is an honest question.)

AFAICS this is an optimization issue only, not a bug per se.
I haven't measured, but I bet such an optimization would
not improve "make clean" time even measureably.
Prove me wrong and we may have a case.  ;-)

Hmm, maybe the code will get faster if we avoid the sed
script when $(EXEEXT) is empty ... will look into that.

Thanks for the report.

Cheers,
Ralf

Re: pre and post install targets

[Ralf Wildenhues]

* Jose-Marcio wrote on Mon, Jul 28, 2008 at 05:27:00PM CEST:
>
> In fact, the real reason, for me, to have another target, is to reuse  
> some configuration values defined during "configure" run, such as  
> prefix, all dirs (sysconfdir, datadir, sbindir, ... ). Maybe it could be  
> interesting to create some kind of "config.vars" file, which could be  
> invoked by another user defined script to setup all variables.
>   . config.vars
>
> But this is more related to autoconf than to automake.

If you mean that all settings should propagate from config.vars to
configure, then config.vars (or a script that sources it) should just
call
  ./configure --prefix=... --sysconfdir=...


If OTOH you mean that all settings should propagate from configure to
config.vars, then you can list config.vars in AC_CONFIG_FILES and create
a file config.vars.in with contents
  prefix='@prefix@'
  datarootdir='@datarootdir@'
  ...

Hope that helps.

Cheers,
Ralf

Re: gnupload and ncftpput

[Ralf Wildenhues]

Hi Karl,

* Karl Berry wrote on Tue, Jul 29, 2008 at 12:30:52AM CEST:
> > 1) do you have any interest in eliminating the dependency on ncftpput?
> 
> Sure.
> 
> So perhaps the best outcome would be for gnupload to use ftp itself,
> instead of ncftpput?  Ie, this stuff could become a function in
> gnupload?

Sure, that would be a possibility, too.  Not sure whether ftp is
universally available, though.

> Failing that, perhaps gnupload could use a variable, e.g.,
> : ${FTPPUT=ncftpput}
> to make it easier to use something else.
> 
> - missing basename could be taken care of.
> 
> What do you mean?  If the result of calling basename is the empty string?

According to the Autoconf manual, some systems don't have a working
basename.  I guess we don't need to cater for those here, presumably
very old systems.

Cheers,
Ralf

Re: dist_bin_SCRIPTS and implicit rules

[Ralf Wildenhues]

Hello Ineiev,

* Ineiev wrote on Mon, Jul 28, 2008 at 11:08:20AM CEST:
> dist_bin_SCRIPTS=src/foo
> bin_PROGRAMS=bar
> bar_SOURCES=src/bar.c src/foo.c
> #When src/foo.c is newer than src/foo,
> #GNU make applies it's implicit rule, like this:
> # gcc -g -O2../ns/src/foo.c   -o src/foo

Yep.  Kinda ugly.  You should be able to work around it by adding
an empty rule:

  src/foo: ;

Cheers,
Ralf

Re: gnupload and ncftpput

[Ralf Wildenhues]

Hi Karl,

* Karl Berry wrote on Mon, Jul 28, 2008 at 02:54:38AM CEST:
> So, I guess my questions are:
> 1) do you have any interest in eliminating the dependency on ncftpput?

Sure.

> 2) do you have any interest in including this ncftpput-replacement
>somewhere, somehow?

Fine with me.  I suppose putting it in gnulib will make it available to
developers more quickly than putting it in Automake, but we could do the
latter, if you wish, too.

Please remove these nonportable constructs from the script:
- $'\n'
- `for f in "$@"; do' is better written as `for fdo'.
- missing basename could be taken care of.

Thanks,
Ralf

Re: best practice for injecting include dir across a project

[Ralf Wildenhues]

Hello Monty,

* Monty Taylor wrote on Thu, Jul 24, 2008 at 08:43:39PM CEST:
> 
> I've got a project that has 24 Makefile.am files. At the top of all of
> them at the moment, I've got:
> 
> AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include

Put
  AC_SUBST([AM_CPPFLAGS], ['I$(top_builddir)/include -I$(top_srcdir)/include'])

in configure.ac instead.

Cheers,
Ralf

Re: Bracketing a "check" target with pre and post actions

[Ralf Wildenhues]

* Bernd Jendrissek wrote on Mon, Jul 21, 2008 at 01:31:46PM CEST:
> On Sun, Jul 20, 2008 at 9:32 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > Why not do it all in check-local?
> >
> > check-local:
> >echo "create database foo;" |psql postgres $(dbsuperuser)
> >psql $(dbname) $(dbuser) -f $(top_srcdir)/whatever/dump.sql
> >echo "drop database foo;" |psql postgres $(dbsuperuser)
> 
> In the end I did that, since I'm now no longer bracketing 'make check'
> but dropping the database just before populating it again.  (It helps
> to do post-mortem analysis of test failures.)  So I didn't need
> anything to run after 'check'.  Just had to add a dependency:
> 
> check-local: check

That looks broken.  check will cause the check-am target to run
'make check-local' which may then call 'make check' again.  You
can run into an endless loop this way, and it is not parallel safe
either.  I also think that you rely on undocumented features here.

> so that the database setup would happen before the testsuite ran.

Hmm, I'm not yet sure how to fix that better.

> > Or do you have a TESTS=... testsuite, rather than the second command
> > being your testsuite?
> 
> I have both TESTS = ... and AM_INIT_AUTOMAKE(dejagnu).  If by "second
> command" you mean "psql ... dump.sql", no, that's just to populate the
> database for the program that runs as a dejagnu "tool" test.

Ah, ok.

Cheers,
Ralf

Re: pre and post install targets

[Ralf Wildenhues]

* Jose-Marcio wrote on Mon, Jul 21, 2008 at 04:46:29PM CEST:
> Ralf Wildenhues wrote:
>>
>>   upgrade:
>>  $(MAKE) $(AM_MAKEFLAGS) preinstall
>>  $(MAKE) $(AM_MAKEFLAGS) install
>>  $(MAKE) $(AM_MAKEFLAGS) postinstall

> Only to let you know. Maybe other people have the same needs than me.  
> There are two reasons I'm doing this.
>
> * My package uses a database library (BerkeleyDB). From time to time,
>   data format changes. So, to install the new release, I need to dump
>   the database using the **old version**, install the new version and
>   recreate databases with the **new version**.
>
> * My software is a mail filter. This filter can be running on a busy
>   server (handling, says, 10 or 20 messages per second). Downtime shall
>   be minimized. The sequence of operations are : stop the MTA, stop the
>   filter, make upgrade, restarts the filter and restarts the MTA. It's
>   pratical and less error prone to have a single command to launch
>   instead of typing all them. Either way, all this can be done with a
>   small shell script.

Well, one reason I'm hesitant is that I think most such pre- or post-
actions are pretty system-dependent, more so than other tasks routinely
done in makefiles.  For example, they would often depend on the type of
GNU/Linux distribution used, rather than only the config.guess triple.
This makes it more attractive to keep them in a separate file, as you
say a small shell script, or a debian/rules entry, or a .rpm stanza or
so.

Cheers,
Ralf

Re: Bracketing a "check" target with pre and post actions

[Ralf Wildenhues]

* Bernd Jendrissek wrote on Mon, Jul 14, 2008 at 02:49:46PM CEST:
> I need to run my testsuite against a PostgreSQL database that I want
> predictably populated with data straight from the source tree, so that
> code version 17 gets tested against data version 17.  How can I teach
> automake to set up the database before running the testsuite, and to
> clean it up afterwards?

> .PHONY: fat-check
> fat-check: check
> echo "drop database foo;" |psql postgres $(dbsuperuser)
> 
> check-local:
> echo "create database foo;" |psql postgres $(dbsuperuser)
> psql $(dbname) $(dbuser) -f $(top_srcdir)/whatever/dump.sql

Why not do it all in check-local?

check-local:
echo "create database foo;" |psql postgres $(dbsuperuser)
psql $(dbname) $(dbuser) -f $(top_srcdir)/whatever/dump.sql
echo "drop database foo;" |psql postgres $(dbsuperuser)

Or do you have a TESTS=... testsuite, rather than the second command
being your testsuite?

Cheers,
Ralf

Re: pre and post install targets

[Ralf Wildenhues]

Hello,

* Bernd Jendrissek wrote on Fri, Jul 18, 2008 at 01:32:34PM CEST:
> On Thu, Jul 17, 2008 at 10:20 AM, Jose-Marcio <[EMAIL PROTECTED]> wrote:
> > Currently, I've defined a new target (upgrade) which depends
> > on :
> >
> > upgrade : preinstall install postinstall
> 
> Note that that breaks under make -j upgrade.

Yep.  If you were to let install depend on preinstall, and postinstall
on install then parallel make works again, but you cannot run
  make postinstall

usefully.  What you can do instead is

  upgrade:
$(MAKE) $(AM_MAKEFLAGS) preinstall
$(MAKE) $(AM_MAKEFLAGS) install
$(MAKE) $(AM_MAKEFLAGS) postinstall

or, if you assume a recent GNU make, then you can use order-only
dependencies:

  install: | preinstall
  postinstall: | install

Note that Automake provides install-{data,exec}-hook to which
postinstall actions may be hooked, as they are run strictly after
(the Automake-provided target named) install.  However, there is no
dedicated target to use for preinstall.

I'm not sure whether we should introduce such pre hooks.

Hope that helps.

Cheers,
Ralf

Re: Add self-contained packaged to Makefile.am

[Ralf Wildenhues]

Hello,

* ulaikamor wrote on Sun, Jul 20, 2008 at 01:09:39PM CEST:
> 
> So, is it possible to add an entry in Makefile.am that simply says to ignore
> all checks on my package and execute the package's Makefile under its own
> conditions?

Probably, but I don't understand your setup enough yet to give specific
advice.  The manual has some general advice about extending:


Hope that helps.

Cheers,
Ralf

Re: sh location

[Ralf Wildenhues]

Hello Christian,

* Christian Csar wrote on Thu, Jul 17, 2008 at 10:05:00PM CEST:
> So in writing test scripts, I happened to read the man page for sh, and
> in APPLICATION USAGE it mentions that
> "Applications should note that the standard PATH to the shell cannot be
> assumed to be either /bin/sh or /usr/bin/sh, and should be determined by
> interrogation of the PATH returned by getconf PATH , ensuring that the
> returned pathname is an absolute pathname and not a shell built-in."
> 
> Does automake provide a way to deal with this, or do modern systems
> primarily use only /bin/sh. This seems as if it could also be a problem
> with python or perl which might have more variable locations. I did not
> find anything about this in the manual, but I could have missed it.

The configure startup code provided by Autoconf searches for a better
shell if the one running is found to be not good enough.  The choice may
be overridden with CONFIG_SHELL, like this:
  CONFIG_SHELL=/bin/foosh /bin/foosh ./configure [OPTIONS...]

as documented in the INSTALL file.

Otherwise, the shell search will typically try bash or ksh, or use
/usr/xpg4/bin/sh.  The result of the shell search will be available in
the $SHELL variable and the @SHELL@ substitute.

Hope that helps.

Cheers,
Ralf

Re: Installation of startup scripts

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Wed, Jul 16, 2008 at 11:39:00PM CEST:
> > Is there a proper automake way of installing startup scripts?
> 
> Try
>   init_d_dir = $(sysconfdir)/rc.d/init.d
>   init_d_dir_SCRIPTS = blah

The last line should've been 
init_d_SCRIPTS = blah

Sorry about that.

Cheers,
Ralf

Re: Installation of startup scripts

[Ralf Wildenhues]

Hello Vikram,

* Vikram Ambrose wrote on Wed, Jul 16, 2008 at 10:38:04PM CEST:
> install:

That should've been install-exec-local.

>install -D -m 755 $(sysconfdir)/rc.d/init.d/blah
>
> uninstall:
>rm $(sysconfdir)/rc.d/init.d/blah
>
> Is there a proper automake way of installing startup scripts?

Try
  init_d_dir = $(sysconfdir)/rc.d/init.d
  init_d_dir_SCRIPTS = blah

HTH.  Cheers,
Ralf

Re: Profiled-arc builds?

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Wed, Jul 16, 2008 at 05:01:28PM CEST:
> On Wed, 16 Jul 2008, Ralf Wildenhues wrote:
>>> execution.  Is this within the realm of possibility for future Automake?
>>
>> No idea.  How are you doing it now?
>
> I am not doing it now, but an example of its successful use is in the  
> GCC build when built via 'make profiledbootstrap'.  For the last several 
> years I have been building GCC this way even though it is much slower to 
> build.

Yes, this is how it works in GCC: stage2 is compiled with
-fprofile-generate, stage3 is compiled with -fprofile-use.
Before stage3 is compiled, the profile output files are
linked or copied around to be in place for use.

GCC is special in that the compiled programs are used to
compile (themselves) in a later stage.

>> Automake isn't magic, it can automate (sorry for the pun) some work
>> flows if they are sufficiently easy to generalize.  The first step
>> in doing so is typically showing how things work manually.
>
> Right.

You could help by doing this manually for your package, from beginning
to end, once.  Keep a log of the commands you use.  Try to generalize
those commands to other packages.  Post the resulting logs.

> It seems that for the first pass, the code is compiled with additional  
> options `-fprofile-generate' and optimization disabled.  After the code 
> is executed to produce '.gcno' and '.gcda' files, the `-fprofile-use' 
> option is used to make use of the profile data while optimizing the 
> program.

Yes; this much I knew from using them at one point in the past.
Here's some things I don't know, and where I would start off
working:

- assume first that 'make check' generates typical program execution.
- start with this command sequence:

  ./configure "CFLAGS=-g -fprofile-generate"
  make all check
  ./configure "CFLAGS=-g -fprofile-use"
  make clean all check

What's necessary to make this sequence do something useful?
Which parts need to be adjusted for packages?  What about VPATH
builds?  What about VPATH builds which used an absolute path for
the configure script?

> The profile data is useful since the most commonly executed 
> code paths are placed first, [...]

Yes, I don't think anybody questions the usefulness of profiling.

I am lacking the free time to fill in the technical details above,
if they are sorted out we can still start looking at whether and
how Automake can help here.

> As an implementation in automake, a new top target can be added which  
> builds the program, executes a user-provided test program (similar to  
> 'check') to collect profile data, cleans the objects, and then builds  
> the optimized version.  There is also the option of coming up with a  
> naming scheme so that the built objects instrumented for profiling can  
> live in the same build tree as the final objects.

First, I think it's too early to ponder such issues, second, typically
Automake encourages to use separate build trees for separate build
options.  Also, new targets aren't added lightly (they always create
a backwards incompatibility, and bloat), so usefulness and viability
should be proved first.

Cheers,
Ralf

Re: Profiled-arc builds?

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Wed, Jul 16, 2008 at 02:51:10AM CEST:
> It it is useful to be able to support profiled builds in which a first  
> build is created, the program is executed, and then a second build is  
> done with code paths optimized based on the branching behavior during  
> execution.  Is this within the realm of possibility for future Automake?

No idea.  How are you doing it now?

Automake isn't magic, it can automate (sorry for the pun) some work
flows if they are sufficiently easy to generalize.  The first step
in doing so is typically showing how things work manually.

Thanks,
Ralf

Re: AC_SEARCH_LIB - search path (?)

[Ralf Wildenhues]

Hi Stefan,

* steve_k wrote on Fri, Jul 11, 2008 at 04:11:59PM CEST:
> 
> my current task is to get some testcases for a library compiling - the
> directory structure is that the testcases should exist completely
> independently from the source directory of the library. Each testcase has
> its own subdirectory seen from the root directory.  The binary(ies) of the
> shared library are placed in /usr/local/lib includes reside in
> /usr/local/include.
> 
> My problem is that the library is never found - by autoreconf - ./configure 

Try
  ./configure LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include

and if that doesn't work, look into config.log, find the sections where
it searches for -lgeneva and why that fails.  There may be undefined
symbols from needed libraries or similar.

Hope that helps.

Cheers,
Ralf