Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Roumen Petrov]

Hi Stefano,

Stefano Lattarini wrote:

On 04/02/2012 10:19 PM, Tom Tromey wrote:

"Stefano" == Stefano Lattarini  writes:

Stefano>  It should still be possible, with the right hack (which is
Stefano>  tested in the testsuite, and required by other packages
Stefano>  anyway).  The baseline is: if you don't want your '.info' files
Stefano>  to be distributed, then it should be easily possible to have
Stefano>  them built in the builddir; but if you want them distributed,
Stefano>  they will be built in the srcdir.

Now I am confused.  Is it possible to continue to work the way it does
today, or not?


The point is: if you want to have info files build in the builddir *and*
distributed, than no, it won't be possible (without bending over backwards).
But I still don't understand why it's a big deal to have the '.info' files
placed in the srcdir *if you are going do distribute them*.


A lot of manual include path to executable. This path depend from vendor 
and OS. The correctly written documentation has to use proper paths
For instance /bin/sh is correct for most system but on some linux based 
OS-es it is /system/bin/sh .


So the rule to put into source tree generated files (documentation) 
prevent parallel build for multiple host or target platforms.



[SNIP]
Roumen

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Ian Lance Taylor]

Stefano Lattarini  writes:

>> Anyway the real use in the src tree is different, IIUC.
>> Info files are built in the build tree by developers, but put in the
>> source tree for distribution.
>>
> In such a setup, what is the issue with having the '.info' files built
> in the srcdir?  It's not like the developers will develop with a
> read-only source tree, right?

There are many different people who build gcc from snapshots, not
releases, for various different reasons.  It would be good if those
people could continue to build from a read-only source directory.  It
would be good if those people could get .info files appropriate to their
source code.  Of course releases should continue to contain .info files.

We do not want .info files to be part of source code control for
development, but we do want them to be part of source code control for
releases.  That means that there is no correct setting for svn:ignore or
whatever.  This can be worked around, it's just a minor pain.

Ian

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/02/2012 10:12 PM, Roumen Petrov wrote:
> Hi Stefano,
> 
> Stefano Lattarini wrote:
>> [SNIP]
>> It should still be possible, with the right hack (which is tested in the
>> testsuite, and required by other packages anyway).  The baseline is: if
>> you don't want your '.info' files to be distributed, then it should be
>> easily possible to have them built in the builddir; but if you want them
>> distributed, they will be built in the srcdir.
> Sound like if user would like to distribute binaries they must be in source 
> directory .
> Why generated file, not required for build process, has to be places in 
> source tree.
>
This is explained in excruciating details in some code comments in the automake
script (in the 'handle_texinfo_helper', more precisely).  I'll just copy and
paste them here:

  #  Until Automake 1.6.3, .info files were built in the
  #  source tree.  This was an obstacle to the support of
  #  non-distributed .info files, and non-distributed .texi
  #  files.
  #
  #  * Non-distributed .texi files is important in some packages
  #where .texi files are built at make time, probably using
  #other binaries built in the package itself, maybe using
  #tools or information found on the build host.  Because
  #these files are not distributed they are always rebuilt
  #at make time; they should therefore not lie in the source
  #directory.  One plan was to support this using
  #nodist_info_TEXINFOS or something similar.  (Doing this
  #requires some sanity checks.  For instance Automake should
  #not allow:
  #  dist_info_TEXINFOS = foo.texi
  #  nodist_foo_TEXINFOS = included.texi
  #because a distributed file should never depend on a
  #non-distributed file.)
  #
  #  * If .texi files are not distributed, then .info files should
  #not be distributed either.  There are also cases where one
  #wants to distribute .texi files, but does not want to
  #distribute the .info files.  For instance the Texinfo package
  #distributes the tool used to build these files; it would
  #be a waste of space to distribute them.  It's not clear
  #which syntax we should use to indicate that .info files should
  #not be distributed.  Akim Demaille suggested that eventually
  #we switch to a new syntax:
  #|  Maybe we should take some inspiration from what's already
  #|  done in the rest of Automake.  Maybe there is too much
  #|  syntactic sugar here, and you want
  #| nodist_INFO = bar.info
  #| dist_bar_info_SOURCES = bar.texi
  #| bar_texi_DEPENDENCIES = foo.texi
  #|  with a bit of magic to have bar.info represent the whole
  #|  bar*info set.  That's a lot more verbose that the current
  #|  situation, but it is not new, hence the user has less to
  #| learn.
  #|
  #|  But there is still too much room for meaningless specs:
  #| nodist_INFO = bar.info
  #| dist_bar_info_SOURCES = bar.texi
  #| dist_PS = bar.ps something-written-by-hand.ps
  #| nodist_bar_ps_SOURCES = bar.texi
  #| bar_texi_DEPENDENCIES = foo.texi
  #|  here bar.texi is dist_ in line 2, and nodist_ in 4.
  #
  #  Back to the point, it should be clear that in order to support
  #  non-distributed .info files, we need to build them in the
  #  build tree, not in the source tree (non-distributed .texi
  #  files are less of a problem, because we do not output build
  #  rules for them).  In Automake 1.7 .info build rules have been
  #  largely cleaned up so that .info files get always build in the
  #  build tree, even when distributed.  The idea was that
  #(1) if during a VPATH build the .info file was found to be
  #absent or out-of-date (in the source tree or in the
  #build tree), Make would rebuild it in the build tree.
  #If an up-to-date source-tree of the .info file existed,
  #make would not rebuild it in the build tree.
  #(2) having two copies of .info files, one in the source tree
  #and one (newer) in the build tree is not a problem
  #because 'make dist' always pick files in the build tree
  #first.
  #  However it turned out the be a bad idea for several reasons:
  #* Tru64, OpenBSD, and FreeBSD (not NetBSD) Make do not behave
  #  like GNU Make on point (1) above.  These implementations
  #  of Make would always rebuild .info files in the build
  #  tree, even if such files were up to date in the source
  #  tree.  Consequently, it was impossible to perform a VPATH
  #  build of a package containing Texinfo files using these
  #  Make implementations.
  #  (Refer to the Autoconf Manual, section "Limitation of
  #  Make", paragraph "VPATH", item "target lookup", for
  #  an account of the differences between these
  #  implementations.)
  #* The GNU Coding Standards require these files to be built
  #  in the source-tree (whe

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/02/2012 10:19 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini  writes:
> 
> Stefano> It should still be possible, with the right hack (which is
> Stefano> tested in the testsuite, and required by other packages
> Stefano> anyway).  The baseline is: if you don't want your '.info' files
> Stefano> to be distributed, then it should be easily possible to have
> Stefano> them built in the builddir; but if you want them distributed,
> Stefano> they will be built in the srcdir.
> 
> Now I am confused.  Is it possible to continue to work the way it does
> today, or not?
>
The point is: if you want to have info files build in the builddir *and*
distributed, than no, it won't be possible (without bending over backwards).
But I still don't understand why it's a big deal to have the '.info' files
placed in the srcdir *if you are going do distribute them*.

> If so, then great.
> 
> If not, then we need some other plan.
>
By looking at the 'handle_texinfo_helper' function in the automake script,
I suspect adding a new Automake option 'info-in-builddir' (say) and an
handful of lines to the automake script might be enough to give you an easy
way to force the '.info' files to be generated in the builddir.  But before
doing so, I'd like to understand why you want so strongly to support such
a setup.

> Tom> But, I see that, according to the Automake manual, I am wrong about that.
> 
> Stefano> Weird, I didn't expect that hack to be documented in the
> Stefano> manual...  And in fact I cannot find it.  Could you please
> Stefano> point me to it?  Thanks.
> 
> http://www.gnu.org/software/automake/manual/automake.html#Cygnus
> 
> "Info files are always created in the build directory, and not in the
> source directory. Packages that don't use the cygnus option can emulate
> this effect by using the no-installinfo option and listing the generated
> info files in the CLEANFILES variable. "
> 
> Re-reading the suggestion here, I can't understand how it would work.
>
Another automake internal hack basically.  For more details, in case you are
interested, see code and comments in the 'automake.in:handle_texinfo_helper'
subroutine, and the test cases txinfo{23,24,25}.test in the Automake
distribution.

> Anyway the real use in the src tree is different, IIUC.
> Info files are built in the build tree by developers, but put in the
> source tree for distribution.
>
In such a setup, what is the issue with having the '.info' files built
in the srcdir?  It's not like the developers will develop with a
read-only source tree, right?

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

> "Stefano" == Stefano Lattarini  writes:

Stefano> It should still be possible, with the right hack (which is
Stefano> tested in the testsuite, and required by other packages
Stefano> anyway).  The baseline is: if you don't want your '.info' files
Stefano> to be distributed, then it should be easily possible to have
Stefano> them built in the builddir; but if you want them distributed,
Stefano> they will be built in the srcdir.

Now I am confused.  Is it possible to continue to work the way it does
today, or not?

If so, then great.

If not, then we need some other plan.

Tom> But, I see that, according to the Automake manual, I am wrong about that.

Stefano> Weird, I didn't expect that hack to be documented in the
Stefano> manual...  And in fact I cannot find it.  Could you please
Stefano> point me to it?  Thanks.

http://www.gnu.org/software/automake/manual/automake.html#Cygnus

"Info files are always created in the build directory, and not in the
source directory. Packages that don't use the cygnus option can emulate
this effect by using the no-installinfo option and listing the generated
info files in the CLEANFILES variable. "

Re-reading the suggestion here, I can't understand how it would work.

Anyway the real use in the src tree is different, IIUC.
Info files are built in the build tree by developers, but put in the
source tree for distribution.

Tom

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Roumen Petrov]

Hi Stefano,

Stefano Lattarini wrote:

[SNIP]
It should still be possible, with the right hack (which is tested in the
testsuite, and required by other packages anyway).  The baseline is: if
you don't want your '.info' files to be distributed, then it should be
easily possible to have them built in the builddir; but if you want them
distributed, they will be built in the srcdir.
Sound like if user would like to distribute binaries they must be in 
source directory .
Why generated file, not required for build process, has to be places in 
source tree.


What if author(s) would like to separate process of document creation 
from binaries ?



  The rationale to do so is
to ensure that, in both cases, the developer's tree layout (as bootstrapped
from a VCS checkout) will match the user's tree layout (as obtained from a
distribution tarball).
May be I miss what is rationale to keep read-only and build-ready source 
tree.


[SNIP]

Roumen

P.S. I'm not member of all list so I just post to automake list.

bug#11153: change automake branching policy: dispensing with the 'branch-X.Y' branches in the future

[Stefano Lattarini]

Hi Jim.

On 04/02/2012 08:47 PM, Jim Meyering wrote:
> Stefano Lattarini wrote:
> ...
>> WDYT?  If you agree, I can apply the change below to HACKING, and
>> implement the new branching policy starting from the Automke 1.12
>> release.
>
> I agree.
> IMHO, you won't go wrong following git.git's example.
>
Glad you agree.

As for your nits you've pointed out: I've fixed them both.

Thanks,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/02/2012 09:36 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini  writes:
> 
> Stefano> Sorry if I sound dense, but what exactly is the feature you are
> Stefano> talking about here?
> 
> I was under the impression that it would no longer be possible to build
> info files in the build tree.
>
It should still be possible, with the right hack (which is tested in the
testsuite, and required by other packages anyway).  The baseline is: if
you don't want your '.info' files to be distributed, then it should be
easily possible to have them built in the builddir; but if you want them
distributed, they will be built in the srcdir.  The rationale to do so is
to ensure that, in both cases, the developer's tree layout (as bootstrapped
from a VCS checkout) will match the user's tree layout (as obtained from a
distribution tarball).

> But, I see that, according to the Automake manual, I am wrong about that.
>
Weird, I didn't expect that hack to be documented in the manual...  And in
fact I cannot find it.  Could you please point me to it?  Thanks.

> So, sorry for the noise.
> 
Well, better safe than sorry :-)

Regards,
  Stefano

bug#11153: change automake branching policy: dispensing with the 'branch-X.Y' branches in the future

[Stefano Lattarini]

Hi Peter, thanks for the feedback.  But I fear we have a misunderstanding
here.  See below.

On 04/02/2012 08:14 PM, Peter Rosin wrote:
> On 2012-04-02 18:13, Stefano Lattarini wrote:
>> Severity: wishlist
>> thanks
>>
>> Hello Automakers.
>>
>> After some real hand-on experience with the current branching policy
>> of Automake, I'm convinced the presence of the 'branch-X.Y' branches
>> is just an annoyance and a source of confusion, and that a better policy
>> would be to simply have a 'maint' branch (where to cut maintenance
>>  releases directly from), a master branch (where maint is to be kept
>> regularly merged into, and from which the next major release is to be
>> derived at last), and possibly topic branches (only when needed, and
>> better if they are short-lived).  Maybe we could also re-add the 'next'
>> branch to serve as common ground for feature merging and testing, but
>> than can be done in a second time (and only if the need arise).
>>
>> When a major release is done, the master branch is to be merged into
>> the maint branch, and then a "new" master branch created stemming
>> from the resulting commit.
> 
> I think what you are proposing is better described as dropping the
> maint branch and doing development of features for both the stable
> series as well as the pending major release directly on the stable
> branch.
>
Absolutely not.  In 'maint' will go bugfixes, minor new features
(with low protability of regressions), and possibly new warnings for
obsoleted features (that might be removed when we pass to a future
"major" version).  In master will go "bigger" new feature, non-trivial
refactorings, and backward-incompatible changes (after their coming
has been duly announced and prepared in 'maint' and/or in earlier
releases).

This is basically the situation we have today, but without the extra
indirections and possibility of confusion (i.e., another 'msvc'-style
mess will be made less likely).

> When you wish to make a new release you simply make sure
> you have merged the latest branch-x.y into master, then create a new
> branch-x. or branch-.0 from where the current master is
> and you're done.
>
You mean that if we have just released automake 1.13, the release
1.13.1 should be cut from master?  That is absolutely *not* what I
want to do.  Sorry if I didn't explain myself clearly enough.

>> WDYT?  If you agree, I can apply the change below to HACKING, and
>> implement the new branching policy starting from the Automke 1.12
>> release.
> 
> Consider what will happen if you don't have maint branches,
>
> [SNIP]
>
I snip mostly of the rest of your arguments, now that it is clear
I still *want* to have a maint branch.

> I think it's immensely more clean to have the current dual maint and
> branch-1.11 approach for each expected bug-fix series.
>
Here I don't follow you.  Why are not 'maint' a 'master' enough exactly?

> When 1.12 is released, maint should probably move along with it
>
Yes, and a "new" master created, from which 1.13 will be finally derived.

> and a maint-1.11 can be created when needed, if a security fix is ever
> needed for the 1.11 series.
>
Agreed.  But we don't need this branch right away, since the last commit
in the 'maint' of the 1.11.x series will be properly tagged, so we can
easily access need and create a bug-fix branch out of it if and when the
need arises.

> Hopefully, we will not need a maint-1.11, but such things
> are as they are...
>
OK, so it sounds like we are in violent agreement in this matter.

> Either that, or you'd need to do dummy merges from branch-x.y into
> master after the release-related commits just to avoid future merge
> conflicts, but dummy merges are ugly in my opinion.  And branches are
> cheap.
>
Tags even more -- you don't pay them with the risk of confusion.

> I think we have learned not to merge new features past the maintenance
> branch (i.e. directly into the release branch)
>
Huh?  That *exactly* what should happen most of the time!  It's the
AM_PROG_AR situation that was an unusual case, in that we didn't want
the delay in the 1.12 release to keep this useful and low-risk feature
as "vaporware" for even more time -- so we merged it into the
maintenance branch.

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

> "Stefano" == Stefano Lattarini  writes:

Stefano> Sorry if I sound dense, but what exactly is the feature you are
Stefano> talking about here?

I was under the impression that it would no longer be possible to build
info files in the build tree.  But, I see that, according to the
Automake manual, I am wrong about that.  So, sorry for the noise.

Tom

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

> "Stefano" == Stefano Lattarini  writes:

Stefano> True, and that was even stated in the manual; the whole point
Stefano> of ditching support for cygnus trees is that by now those two
Stefano> big users are basically not making any real use of the 'cygnus'
Stefano> option anymore.  To quote my previous report:

Stefano>   ./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus
Stefano>   ./bfd/doc/Makefile.in:# cygnus option.
Stefano>   ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
Stefano>   ./bfd/doc/Makefile.am:# cygnus option.

But this is a reason not to remove it; or at least to restore the
previous handling of info files.

I don't care about the cygnus option per se.  It was always a grab bag
of hacks.  The issue is removing a feature that an important user relies
on.  So far the suggested replacements haven't seemed that good to me.

Tom

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

> "Stefano" == Stefano Lattarini  writes:

Stefano> Note there's nothing I'm planning to do, nor I should do, in
Stefano> this regard: the two setups described above are both already
Stefano> supported by the current automake implementation (but the last
Stefano> one is not encouraged, even though it makes perfect sense in
Stefano> some *rare* situations).  I was just pointing out that you have
Stefano> to choose one of these setups -- so, if you want to distribute
Stefano> info files, you must accept to have them build in the srcdir.

Or we can just stick with an older version of automake.
It seems to me that this is the sensible approach.

Or move to some other build system; either autogen-based or just
requiring GNU make features.  The latter is fine for GCC but I'm not
sure whether all the src projects are on board.

I'm pretty disappointed that automake would make this change.  I realize
these choices may (arguably) make the most sense for most projects, but
the gcc and src trees are not like most projects; and really the whole
'cygnus' feature is there just to support these two big users.

Tom

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/02/2012 05:16 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini  writes:
> 
> Stefano> True, and that was even stated in the manual; the whole point
> Stefano> of ditching support for cygnus trees is that by now those two
> Stefano> big users are basically not making any real use of the 'cygnus'
> Stefano> option anymore.  To quote my previous report:
> 
> Stefano>   ./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus
> Stefano>   ./bfd/doc/Makefile.in:# cygnus option.
> Stefano>   ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
> Stefano>   ./bfd/doc/Makefile.am:# cygnus option.
> 
> But this is a reason not to remove it; or at least to restore the
> previous handling of info files.
>
> I don't care about the cygnus option per se.  It was always a grab bag
> of hacks.
>
And it's the hacks I'd like to remove, not the option per se :-)

> The issue is removing a feature that an important user relies on.
> So far the suggested replacements haven't seemed that good to me.
>
Sorry if I sound dense, but what exactly is the feature you are talking
about here?

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/02/2012 04:25 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini  writes:
> 
> Stefano> Note there's nothing I'm planning to do, nor I should do, in
> Stefano> this regard: the two setups described above are both already
> Stefano> supported by the current automake implementation (but the last
> Stefano> one is not encouraged, even though it makes perfect sense in
> Stefano> some *rare* situations).  I was just pointing out that you have
> Stefano> to choose one of these setups -- so, if you want to distribute
> Stefano> info files, you must accept to have them build in the srcdir.
> 
> Or we can just stick with an older version of automake.
> It seems to me that this is the sensible approach.
>
> Or move to some other build system; either autogen-based or just
> requiring GNU make features.
>


  In this later case, you might want to take a look at the Automake-NG fork,
  started by myself (and still in a VERY early stage):

   - https://lists.gnu.org/mailman/listinfo/automake-ng

  Fork which will possibly be the subject of the oncoming Google summer of
  code:

   - http://www.gnu.org/software/soc-projects/ideas-2012.html#automake



> The latter is fine for GCC but I'm not sure whether all the src projects
> are on board.
> 
> I'm pretty disappointed that automake would make this change.  I realize
> these choices may (arguably) make the most sense for most projects, but
> the gcc and src trees are not like most projects; and really the whole
> 'cygnus' feature is there just to support these two big users.
>
True, and that was even stated in the manual; the whole point of ditching
support for cygnus trees is that by now those two big users are basically
not making any real use of the 'cygnus' option anymore.  To quote my
previous report:

And as of today, almost any use of the 'cygnus' option has disappeared
from the GCC and GDB trees; for example, the command:

  grep cygnus `find -name '*configure*' -o -name '*[Mm]akefile*' \
-o -name '*.am' -o -name '*.mk'`

yields this in the GCC tree:

  ./zlib/Makefile.am:AUTOMAKE_OPTIONS = 1.8 cygnus
  ./zlib/Makefile.in:AUTOMAKE_OPTIONS = 1.8 cygnus

and this in the GDB tree:

  ./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus
  ./bfd/doc/Makefile.in:# cygnus option.
  ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
  ./bfd/doc/Makefile.am:# cygnus option.
  ./etc/configure.texi:option of @file{/usr/cygnus/@var{release}}, where 
@var{release} is the
  ./etc/configure.texi:@file{/usr/cygnus/@var{release}/H-@var{host}}, where 
@var{host} is the
  ./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus
  ./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus 1.3
  ./etc/configure.texi:@cindex canadian cross in cygnus tree
  ./etc/configure.texi:@cindex cygnus configure

Regards,
  Stefano

Release an early beta for automake 1.12

[Stefano Lattarini]

Reference:
 

Hello Automakers.

I plan to release a beta for Automake 1.12 in the next days, with the
estimated release date set a couple of weeks after that.  If anyone
knows about any pending or new issue for which such a beta release
should be postponed, now would be a good moment to speak up.

Thanks,
  Stefano

Automake 1.11.4 released

[Stefano Lattarini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We are pleased to announce the Automake 1.11.4 maintenance release.

This is mostly a bugfix release, fixing few recent and long-standing
bugs.

It also contains minor enhancements to the 'ar-lib' and 'compile' script
(thanks to Peter Rosin), and adds support for automatic dependency tracking
with the IBM XL C/C++ compiler (thanks to Michael Hofmann) and the Tiny C
Compiler (thanks to prodding by Vincent Lefevre, see automake bug#11007).

The most important change is surely the fact that the install rules do not
create an empty '$(foodir)' directory anymore when an empty "foo_PRIMARY"
is declared (conditionally or unconditionally) in Makefile.am.  See automake
bugs #11030 and #10997:

  
  

See below for the detailed list of changes since Automake 1.11.3, as
summarized by the NEWS file.

Download here:

  ftp://ftp.gnu.org/gnu/automake/automake-1.11.4.tar.gz
  ftp://ftp.gnu.org/gnu/automake/automake-1.11.4.tar.xz

Please report bugs and problems to , and send
general comments and feedback to .

Thanks to everyone who has reported problems, contributed patches,
and helped testing Automake!

- -*-*-

New in 1.11.4:

* Miscellaneous changes:

  - The 'ar-lib' script now ignores the "s" (symbol index) and "S" (no
symbol index) modifiers as well as the "s" action, as the symbol index
is created unconditionally by Microsoft lib.  Also, the "q" (quick)
action is now a synonym for "r" (replace).  Also, the script has been
ignoring the "v" (verbose) modifier already since Automake 1.11.3.

  - When the 'compile' script is used to wrap MSVC, it now accepts an
optional space between the -I, -L and -l options and their respective
arguments, for better POSIX compliance.

  - Automatic dependency tracking now works also with the IBM XL C/C++
compilers, thanks to the new new depmode 'xlc'.

  - There is an initial, experimental support for automatic dependency
tracking with tcc (the Tiny C Compiler).  Its associated depmode is
currently recognized as "icc" (but this and other details are likely
to change in future versions).

Bugs fixed in 1.11.4:

* Bugs introduced by 1.11.2:

  - A definition of 'noinst_PYTHON' before 'python_PYTHON' (or similar)
don't cause spurious failures upon "make install" anymore.

  - The user can now instruct the 'uninstall-info' rule not to update
the '${infodir}/dir' file by exporting the environment variable
'AM_UPDATE_INFO_DIR' to the value "no".  This is done for consistency
with how the 'install-info' rule operates since automake 1.11.2.

* Long-standing bugs:

  - It is now possible for a foo_SOURCES variable to hold Vala sources
together with C header files, as well as with sources and headers for
other supported languages (e.g., C++).  Previously, only mixing C and
Vala sources was supported.

  - If "aclocal --install" is used, and the first directory specified with
'-I' is non-existent, aclocal will now create it before trying to copy
files in it.

  - An empty declaration of a "foo_PRIMARY" don't cause anymore the
generated install rules to create an empty $(foodir) directory;
for example, if Makefile.am contains something like:

  pkglibexec_SCRIPTS =
  if FALSE
  pkglibexec_SCRIPTS += bar.sh
  endif

the $(pkglibexec) directory will not be created upon "make install".
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPeZq8AAoJEPyBjhdCn5bq4ZYP/2HAy+GNAloEiYFRoy0mEpVz
+fnuUoZSZP1Pr70yxJjYSA5IMiwEWlyuKgABcclFds4z78Uz1tbyJOcFw1ToKMuu
YX8B+5uwPpm07xFMVlqp2W1ZOHfXbl8fXlhP6U8RcUWsEXYfEwxznTHWoP8GuKG2
LJDUrohN2UkhFTNqSK3N6ToqWODnz/vcnwOVX1pxUgaZQFfcnWD5ZgxtatnRZrUf
5+qUgxgmq8+mb2oWNGuEzG8uAhmW2Y+Nh+l9PR5tRJeU7BQLh/PEgwbtsNJS+XAW
gJvGSUSX0te1RtbDHLqAK97Xp5yh8AZetyk5qFk8vhyOusbsmLM7j9Yqi5lj8GZ6
KMoa1xtWqJpdwMoq3gmZGy9rxfCtX58cAr4/r1TpQiYI1Jjlr0xq2oyjSQesmuOG
yH100HO+4ci+tWdQt3TS0qa1rHDOVAC76pLvp2O6h17DPzEzmQvzByuDoH7mANv/
JYbqt4DIZtYQHzt5jZZbiFhRFRMSzldW7IZskb2b/JOI0lXI/0tqSgTf2RnRICOV
v4JHOGeqCcksok4vqt/a0oBS/qsodzIuBgcbT+eA98Mt76s7livSiuAApwRiOBpm
LEG9t9E07wJppkD4K1KH1os4WgW+bftByGVnitc2iJxlsDBaVr7tlLP6bMn39nQR
s0HgrJRjQL3L+j4by+Oj
=M61v
-END PGP SIGNATURE-

Re: Target depending variables?

[Stefano Lattarini]

On 04/01/2012 06:52 PM, Jules Colding wrote:
> Hi,
> 
> I'd like my SUBDIRS variable not to be set when, and only when,
> the target is distclean. I can't seem to find a way to do that
> in my Makefile.am. Is it possible at all?
>
If you can assume GNU make, yes:

  SUBDIRS = foo bar
  distclean-recursive: SUBDIRS =

If you need something that works also with non-GNU make implementations,
you could resort to the following hack (which abuses Automake internal
details):

  distclean-recursive:
  RECURSIVE_CLEAN_TARGETS = \
mostlyclean-recursive \
clean-recursive \
maintainer-clean-recursive

Note that there is no assurance this will continue to work with future
versions of Automake.

HTH,
  Stefano

Target depending variables?

[Jules Colding]

Hi,

I'd like my SUBDIRS variable not to be set when, and only when, the target is 
distclean. I can't seem to find a way to do that in my Makefile.am. Is it 
possible at all?

Thanks,
  jules