Re: GNU make or portable make?

[Ralf Wildenhues]

Hi Tom,

* Tom Tromey wrote on Wed, Aug 18, 2010 at 12:21:19AM CEST:
> The "make" part of the build parallelizes well, but the configure part
> does not.

Yet.

> I think that is the big problem today.  It is particularly
> noticeable in big trees like gcc or gdb.

Both of whose build systems could use a bit of love, but yes, granted.

> GNU make could help solve this.  See quagmire for a random stab at this
> idea.  It isn't the most pleasant programming environment, but then
> neither is the m4+shell combination ;-).  I'm sure there are other
> workable approaches as well.

As much as I have sympathy with you for quagmire, I don't think it's the
way I would go (wouldn't have said so had you not brought it up ;-)
If one chooses to ditch the current system and start anew, I think it
should both be simpler to program in, and it should have the right
complexity for the edit-compile-test cycle even in very large trees,
which so far only tup[1] has, but that again doesn't fulfill a lot of
other needs.

But again, I don't think autoconf is at the end of the road in enabling
more Posix and XSI shell, nor have we seriously tried parallelism there
yet (but now we have experience from Autotest).

Cheers,
Ralf

[1] 

Re: GNU make or portable make? (was: Makefile to Makefile.am)

[Robert J. Hansen]

> I for one would be glad if automake required GNU make, since it
> could make use of a lot of useful features which currently aren't
> allowed.  Similar to autoconf not requiring a POSIX shell, depite
> the fact that non-POSIX shells are so far obsolete they are
> irrelevant.

Are there any tools to spot GNUisms in Makefiles?  If not, it seems like this 
would be a useful thing to develop.

Re: GNU make or portable make?

[Bob Friesenhahn]

On Tue, 17 Aug 2010, Tom Tromey wrote:


"Ralf" == Ralf Wildenhues  writes:


Ralf> If Automake were only started now, I think requiring GNU make
Ralf> would be a prudent design decision.

Yeah.  Portability looked a lot more important back then.  Nowadays I
think assuming GNU make is completely reasonable.  You can probably even
dig up cases where the configury for a project is bigger than GNU make
itself... you could shrink some programs by shipping the build tool :-)


If there is thinking to require GNU make, then there should be a bit 
more thinking as well.  A specialized mini-shell intended to run 
configure scripts and perform substitutions would be quite useful.  It 
would eliminate the shell portability issue and eliminate the need to 
fork to perform functionality like 'sed'.  The current approach 
requires that each package provide full configure/build capability 
using only portable aspects of tools and with no special build 
software (e.g. m4 macros) already installed on the system.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: GNU make or portable make?

[Tom Tromey]

> "Ralf" == Ralf Wildenhues  writes:

Ralf> If Automake were only started now, I think requiring GNU make
Ralf> would be a prudent design decision.

Yeah.  Portability looked a lot more important back then.  Nowadays I
think assuming GNU make is completely reasonable.  You can probably even
dig up cases where the configury for a project is bigger than GNU make
itself... you could shrink some programs by shipping the build tool :-)

Ralf> Still, as things stand, I'm not sure whether changing design goals of
Ralf> Automake now are such a good idea.  BSD developers really like using
Ralf> their own make.  The code we have works, build system overhead is really
Ralf> bad only on w32.  We have opportunities for improvement by assuming
Ralf> Posix and XSI shell in more places, guarded by suitable tests.  As long
Ralf> as the build system parallelizes well, I don't think there is too much
Ralf> cause for concern.

The "make" part of the build parallelizes well, but the configure part
does not.  I think that is the big problem today.  It is particularly
noticeable in big trees like gcc or gdb.

GNU make could help solve this.  See quagmire for a random stab at this
idea.  It isn't the most pleasant programming environment, but then
neither is the m4+shell combination ;-).  I'm sure there are other
workable approaches as well.

Tom

Re: GNU make or portable make? (was: Makefile to Makefile.am)

[Roger Leigh]

On Tue, Aug 17, 2010 at 10:05:31PM +0200, Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Mon, Aug 16, 2010 at 05:06:40PM CEST:
> > If depending on GNU make was considered ok, then Automake would have
> > been developed quite differently than it is.  Given current Automake
> > objectives, it is wise that individual projects also try to avoid
> > GNU make syntax in Makefile.am.
> 
> While I don't dispute that, I do think that requiring GNU make is a
> fairly low barrier in way of prerequisites.  GNU make is small, highly
> portable and easily installed.  If Automake were only started now, I
> think requiring GNU make would be a prudent design decision.
> 
> The current Automake code contains large chunks of logic that exists
> purely to work around missing features or issues in non-GNU make
> implementations.  Let's be honest, requiring GNU make outright would
> make several optimizations possible, leading to smaller makefiles
> and lower build system overhead.  We've been at the point before where
> some new feature was easily implemented in GNU make syntax but rather
> tough in portable make.  Some features may not be possible at all with
> the latter.

As someone who tried hard to keep their project's Makefiles portable
across all vendor make variants, I'd just like to point out that in
practice most projects end up dependent upon GNU make, even if that
wasn't their deliberate intention.  If your primary development
environment is GNU-based such as GNU/Linux, or even MSYS, your primary
testing is always with GNU make and non-portable things won't be found.

I spent a lot of time making sure BSD and Solaris makes worked
correctly, but unless you've got people testing every release against
all other makes, GNU make-isms gradually creep back in.  In my case
the cost of the testing was not worth the benefit--no one else was
using those platforms regularly enough and we ended up simply
mandating GNU make in any case.  A similar story has played out for
all of the projects I've been involved with: while in theory automake
produces portable Makefiles, in practice they are not.  The reality
was that for the odd single user using BSD who ran into problems, the
answer was just to build with gmake.

I for one would be glad if automake required GNU make, since it
could make use of a lot of useful features which currently aren't
allowed.  Similar to autoconf not requiring a POSIX shell, depite
the fact that non-POSIX shells are so far obsolete they are
irrelevant.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Testing a new compiler with Automake "simple tests"

[Stefano Lattarini]

At Tuesday 17 August 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Tue, Aug 17, 2010 at 09:37:22PM CEST:
> > At this point I can think only of two ways out:
> I'd go with the previous solution or use the *_OBJECTS variables.
> It's not likely that they change.
But this would involve a lot of repetion, wouldn't it?  For example, 
instead of:

  TESTS = t1 t2 t3 t4 t5 t6
  $(TESTS:=...@objext@): my-compiler

one has to write e.g.:

  TESTS = t1 t2 t3 t4 t5 t6
  $(t1_OBJECTS) $(t2_OBJECTS) $(t3_OBJECTS) $(t4_OBJECTS) \
  $(t5_OBJECTS) $(t6_OBJECTS): my-compiler

And this just becomes worse and worse as the number of tests 
increases...

But, thinking about it, my "solution" of dummy header inclusion would
involve an equal amount of repetition, while being much more hackish.
So your solution still seems the best available...

> > As an aside: Ralf, do you think this variables are stable enough
> > to be documented?  If yes, do you think doing so would be
> > worthwhile?
> 
> They are fairly stable, but the conditionals logic does weird
> things which I'm not sure would never need changing, so I'd prefer
> not documenting them at this point.
Ok, agreed.

Regards,
   Stefano

Re: Testing a new compiler with Automake "simple tests"

[Ralf Wildenhues]

* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 09:37:22PM CEST:
> At this point I can think only of two ways out:

I'd go with the previous solution or use the *_OBJECTS variables.
It's not likely that they change.

> As an aside: Ralf, do you think this variables are stable enough to be 
> documented?  If yes, do you think doing so would be worthwhile?

They are fairly stable, but the conditionals logic does weird things
which I'm not sure would never need changing, so I'd prefer not
documenting them at this point.

Cheers,
Ralf

[PATCHES] Docs on automatic dependency tracking (was: Testing a new compiler with Automake "simple tests")

[Stefano Lattarini]

[From a discussion on autom...@gnu.org]

At Tuesday 17 August 2010, Roberto Bagnara wrote:
> On 08/17/10 13:26, Stefano Lattarini wrote:
> > At Tuesday 17 August 2010, Roberto Bagnara wrote:
> >> I would like to test a new special-purpose compiler
> >> (which is part of a bigger project) using the Automake
> >> "simple tests" feature.
> >> 
> >> I have two problems:
> >> [CUT]
> >> 2) Automatic dependency tracking cannot work in
> >>that directory of the project (indeed, the only
> >>dependency is on the compiler... all the test
> >>programs are self-contained).  How can I disably
> >>automatic dependency tracking *only* on that
> >>directory?
> > 
> > What about adding `no-dependencies' to AUTOMAKE_OPTIONS
> > in that directory's Makefile.am?  The documentation at
> > 
> > reads:
> >"no-dependencies: This is similar to using --ignore-deps on
> >the command line, but is useful for those situations where you
> >don't have the necessary bits to make automatic dependency
> >tracking work (see Dependencies).  In this case the effect
> >is to effectively disable automatic dependency tracking."
> 
> Yes, this works.  Sorry for not having looked at the manual
> carefully enough (not that I did not try).
The attached patch n.2 should make it harder to miss this bit of
information when looking through the manual.  The patch n.1 is
just a typofix.  Ok to apply to maint?

Regards,
  Stefano
From ef90f67c33297b361ac9630fd5fa8be5d2e463d5 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini 
Date: Tue, 17 Aug 2010 19:23:47 +0200
Subject: [PATCH 1/2] Fix typo in manual (`Makefile.in' instead of `Makefile.am').

* doc/automake.texi (Automatic dependency tracking): Ditto.
---
 ChangeLog |5 +
 doc/automake.texi |2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 5453722..dbab59d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2010-08-17  Stefano Lattarini  
+
+	Fix typo in manual (`Makefile.in' instead of `Makefile.am').
+	* doc/automake.texi (Automatic dependency tracking): Ditto.
+
 2010-08-10  Stefano Lattarini  
 
 	Tweak and/or extend some `acloca*.test' tests.
diff --git a/doc/automake.texi b/doc/automake.texi
index 7484a76..6be1443 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -6768,7 +6768,7 @@ vs.@: @code{LIBOBJS}, autoconf, The Autoconf Manual})
 @section Automatic dependency tracking
 
 As a developer it is often painful to continually update the
-...@file{makefile.in} whenever the include-file dependencies change in a
+...@file{makefile.am} whenever the include-file dependencies change in a
 project.  Automake supplies a way to automatically track dependency
 changes (@pxref{Dependency Tracking}).
 
-- 
1.7.1

From e701a503993423ec559eb7b90135fe7dce724eef Mon Sep 17 00:00:00 2001
From: Stefano Lattarini 
Date: Tue, 17 Aug 2010 22:19:08 +0200
Subject: [PATCH 2/2] Docs: clarify how to avoid automatic dependencies tracking.

* doc/automake.texi (Automatic dependency tracking): Tell that
automatic dependencies tracking is on by default, but that the
package developer can disable it altogether.  Add a referencw
to the proper section for a more in-depth explanation.
---
 ChangeLog |6 ++
 doc/automake.texi |5 +
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index dbab59d..31e0bce 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2010-08-17  Stefano Lattarini  
 
+	Docs: clarify how to avoid automatic dependencies tracking.
+	* doc/automake.texi (Automatic dependency tracking): Tell that
+	automatic dependencies tracking is on by default, but that the
+	package developer can disable it altogether.  Add a referencw
+	to the proper section for a more in-depth explanation.
+
 	Fix typo in manual (`Makefile.in' instead of `Makefile.am').
 	* doc/automake.texi (Automatic dependency tracking): Ditto.
 
diff --git a/doc/automake.texi b/doc/automake.texi
index 6be1443..e86a55d 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -1246,6 +1246,11 @@ source being compiled).  Later, any time @command{make} is run and a
 dependency appears to have changed, the dependent files will be
 rebuilt.
 
+By default, Automake generates code for such an automatic dependency
+tracking. Note, however, that the developer can override this, and
+avoid automatic dependency tracking altogether; see @ref{Dependencies}
+for more information.
+
 When @command{configure} is executed, you can see it probing each
 compiler for the dependency mechanism it supports (several mechanisms
 can be used):
-- 
1.7.1

GNU make or portable make? (was: Makefile to Makefile.am)

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Mon, Aug 16, 2010 at 05:06:40PM CEST:
> If depending on GNU make was considered ok, then Automake would have
> been developed quite differently than it is.  Given current Automake
> objectives, it is wise that individual projects also try to avoid
> GNU make syntax in Makefile.am.

While I don't dispute that, I do think that requiring GNU make is a
fairly low barrier in way of prerequisites.  GNU make is small, highly
portable and easily installed.  If Automake were only started now, I
think requiring GNU make would be a prudent design decision.

The current Automake code contains large chunks of logic that exists
purely to work around missing features or issues in non-GNU make
implementations.  Let's be honest, requiring GNU make outright would
make several optimizations possible, leading to smaller makefiles
and lower build system overhead.  We've been at the point before where
some new feature was easily implemented in GNU make syntax but rather
tough in portable make.  Some features may not be possible at all with
the latter.

Still, as things stand, I'm not sure whether changing design goals of
Automake now are such a good idea.  BSD developers really like using
their own make.  The code we have works, build system overhead is really
bad only on w32.  We have opportunities for improvement by assuming
Posix and XSI shell in more places, guarded by suitable tests.  As long
as the build system parallelizes well, I don't think there is too much
cause for concern.


For your own Makefile.am code, you can turn off warnings about
nonportable constructs by adding -Wno-portability to the automake
options.

Cheers,
Ralf

pattern rules example (was: Makefile to Makefile.am)

[Ralf Wildenhues]

[ automake-patches@ added; followups can drop automake@ ]

Hello Thien-Thi,

* Thien-Thi Nguyen wrote on Mon, Aug 16, 2010 at 02:22:31AM CEST:
> () Ralf Wildenhues
> () Sun, 15 Aug 2010 23:32:44 +0200
> 
>Yes, with a general example, please.
> 
> I am unsure what "general example" means, precisely, so
> the patch below simply uses the one in The GNU Make Manual.
> Is that ok?

The explanation is good, but there are a couple of reasons I'd prefer a
slightly different example: first, automake already generates rules for
compiling .c sources by itself, so this example should never be needed
for Automake users; then, the automake-generated rules are slightly
different: $(CPPFLAGS) come before $(CFLAGS), there are also the AM_*
or per-target flags, and .o might be .obj, giving rise to $(OBJEXT).

Further, there is the SUFFIXES variable to which suffixes should be
added when they are not of the default form.

Can we find a transformation that is known to most readers, not already
done by automake, general enough to be portable, and short enough to
serve as a quick example?  If a real-world one can't be found, then we
can still use a fake .foo -> .bar one.

Then, the placement of the description isn't optimal.  The "Multiple
Outputs" node is specifically about creating multiple output files with
a single rule.  A pattern example would better fit in the "Suffixes"
node; a cross reference from the "Multiple Outputs" node is a good idea
though, as in "see @ref{...} for more discussion of pattern rules".

Thanks,
Ralf

> Subject: [PATCH] Document a common conversion for GNU make pattern rules.
> 
> * doc/automake.texi (Multiple Outputs): Expand on GNU make
> pattern rules; explain how to convert a common case to use
> old-fashioned suffix rules; add simple example, xref.

> --- a/doc/automake.texi
> +++ b/doc/automake.texi
> @@ -11525,11 +11525,31 @@ @node Multiple Outputs
>  @c $$
>  
>  For completeness it should be noted that GNU @command{make} is able to
> -express rules with multiple output files using pattern rules
> -(@pxref{Pattern Examples, , Pattern Rule Examples, make, The GNU Make
> -Manual}).  We do not discuss pattern rules here because they are not
> -portable, but they can be convenient in packages that assume GNU
> -...@command{make}.
> +express rules with multiple output files using pattern rules.
> +Although pattern rules are not portable, they can be
> +convenient in packages that assume GNU @command{make}.
> +...@xref{pattern Examples, , Pattern Rule Examples, make, The GNU Make
> +Manual}.
> +
> +In the common case where the @samp{%} in the pattern rule is used to
> +match the stem of a filename, and the prerequisite and target differ
> +only in the filename extension, you can use the old fashioned suffix
> +rule instead.  For example:
> +
> +...@example
> +# pattern rule, not portable
> +%.o : %.c
> +$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@@ $<
> +
> +# old fashioned suffix rule, portable
> +.c.o:
> +$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@@ $<
> +...@end example
> +
> +Take care, when converting from pattern rule syntax to suffix rule
> +syntax, to place the prerequisite extension @file{.c} before that
> +of the target extension @file{.o}.
> +...@xref{suffix Rules, , Old-Fashioned Suffix Rule, make, The GNU Make 
> Manual}.

Re: Testing a new compiler with Automake "simple tests"

[Stefano Lattarini]

At Tuesday 17 August 2010, Ralf Wildenhues wrote:
> > If every test program is built from a single `.c' file, what
> > about using this instead:
> >   $(TESTS:=.o) your-special-purpose-compiler
> > 
> > It should also be portable make AFAIK.
> 
> This doesn't take into account that object file names are an
> internal detail of Automake.  In practice, they might end in .obj,
> as Stefano already noted, which $(OBJEXT) or @OBJEXT@ can tell
> you, but also, object files may be renamed due to one of several
> reasons such as per-target flags, (obsolete) KnR support, and
> others.
Nice catch, I keep forgotting that.

At this point I can think only of two ways out:
  1. Ensure that no object files' renaming takes place, by writing
 the `tests/Makefile.am' carefully.  This means in particular
 that per-target flags cannot be used, which, depending on the
 situation, might or might not be a serious limit.
  2. Re-enable automatic dependency tracking also for test programs,
 and make *every* source file used by these programs include a
 dummy header file which is updated every time the compiler under
 test is modified.  Yuck.

> I'm mentioning @OBJEXT@ because
>   $(TESTS:=$(OBJEXT)): compiler
> 
> is not portable to some make implementations,
Sorry, didn't know that; I can test only with GNU make, Solaris make 
and FreeBSD make.  They all worked with my snippet.
> while
>   $(TESTS:=...@objext@): compiler
> 
> is.  Also, if your tests contain scripts as well,
>   $(check_PROGRAMS:=...@objext@): compiler
> 
> or EXTRA_PROGRAMS may be more correct.
> 
> There are usually undocumented variables which hold the lists of
> objects which you could use but then be forced to check whether
> updating to a new Automake might have broken things (unlikely
> case, but possible).
As an aside: Ralf, do you think this variables are stable enough to be 
documented?  If yes, do you think doing so would be worthwhile?

Regards,
   Stefano

Re: Testing a new compiler with Automake "simple tests"

[Ralf Wildenhues]

* Stefano Lattarini wrote on Tue, Aug 17, 2010 at 02:26:13PM CEST:
> At Tuesday 17 August 2010, Roberto Bagnara wrote:
> > On 08/17/10 13:26, Stefano Lattarini wrote:
> > >$(TESTS): your-special-purpose-compiler
> > 
> > That dependency cases relinking whenever the compiler
> > changes, whereas I need recompilation.
> Obviously you're right, sorry for not thinking this through.
> If every test program is built from a single `.c' file, what
> about using this instead:
>   $(TESTS:=.o) your-special-purpose-compiler
> It should also be portable make AFAIK.

This doesn't take into account that object file names are an internal
detail of Automake.  In practice, they might end in .obj, as Stefano
already noted, which $(OBJEXT) or @OBJEXT@ can tell you, but also,
object files may be renamed due to one of several reasons such as
per-target flags, (obsolete) KnR support, and others.

I'm mentioning @OBJEXT@ because
  $(TESTS:=$(OBJEXT)): compiler

is not portable to some make implementations, while
  $(TESTS:=...@objext@): compiler

is.  Also, if your tests contain scripts as well,
  $(check_PROGRAMS:=...@objext@): compiler

or EXTRA_PROGRAMS may be more correct.


There are usually undocumented variables which hold the lists of objects
which you could use but then be forced to check whether updating to a
new Automake might have broken things (unlikely case, but possible).

> > Do you know if there is a way I can force Automake
> > to add a dependency on the compiler in the .c.o rule?
> > That is, to generate:
> > 
> > .c.o:   my-special-purpose-compiler
> > $(AM_V_CC) \
> > $(COMPILE) -c $<
> > 
> No, sorry; I don't even think it's possible (but I'm not sure about 
> it, either).

FWIW, it is not portable to all make implementations to specify
dependencies to an inference rule.  It should be done separately.

Cheers,
Ralf

Re: Testing a new compiler with Automake "simple tests"

[Stefano Lattarini]

Just a quick follow-up...

> > If every test program is built from a single `.c' file, what
> > about using this instead:
> >$(TESTS:=.o) your-special-purpose-compiler
Or better again, to be even more portable:
  $(TESTS:=.$(OBJEXT)) your-special-purpose-compiler

Regards,
   Stefano

Re: Testing a new compiler with Automake "simple tests"

[Roberto Bagnara]

On 08/17/10 14:26, Stefano Lattarini wrote:

Obviously you're right, sorry for not thinking this through.
If every test program is built from a single `.c' file, what
about using this instead:
   $(TESTS:=.o) your-special-purpose-compiler
It should also be portable make AFAIK.


Yes!

TESTS_OBJS = $(TESTS:=.o)
$(TESTS_OBJS): my-special-purpose-compiler


Yes, this works.  Sorry for not having looked at the manual
carefully enough (not that I did not try).

Well, I think it's not your fault: that option should be at least
mentioned in the "Dependency Tracking" section.  This can probably be
seen as a documentation bug.  Maybe I'll attempt a patch later or
tomorrow.


Yes, that would be a definite improvement.
Thanks again,

   Roberto

--
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it

Re: Testing a new compiler with Automake "simple tests"

[Stefano Lattarini]

At Tuesday 17 August 2010, Roberto Bagnara wrote:
> On 08/17/10 13:26, Stefano Lattarini wrote:
> > At Tuesday 17 August 2010, Roberto Bagnara wrote:
> >> I would like to test a new special-purpose compiler
> >> (which is part of a bigger project) using the Automake
> >> "simple tests" feature.
> >> 
> >> I have two problems:
> >> 
> >> 1) I have not found a way to force recompilation
> >> 
> >>  of all test programs whenever the compiler executable
> >>  has changed.  Note that we are talking about
> >>  thousands of test programs so, if at all possible,
> >>  I would like to avoid listing that dependency
> >>  for each one of those.
> > 
> > Maybe I don't understand the problem, but... what's wrong
> > 
> > with:
> >$(TESTS): your-special-purpose-compiler
> > 
> > or something similar?
> 
> That dependency cases relinking whenever the compiler
> changes, whereas I need recompilation.
Obviously you're right, sorry for not thinking this through.
If every test program is built from a single `.c' file, what
about using this instead:
  $(TESTS:=.o) your-special-purpose-compiler
It should also be portable make AFAIK.

> Do you know if there is a way I can force Automake
> to add a dependency on the compiler in the .c.o rule?
> That is, to generate:
> 
> .c.o: my-special-purpose-compiler
>   $(AM_V_CC) \
>   $(COMPILE) -c $<
> 
No, sorry; I don't even think it's possible (but I'm not sure about 
it, either).

> >> 2) Automatic dependency tracking cannot work in
> >> 
> >>  that directory of the project (indeed, the only
> >>  dependency is on the compiler... all the test
> >>  programs are self-contained).  How can I disably
> >>  automatic dependency tracking *only* on that
> >>  directory?
> > 
> > What about adding `no-dependencies' to AUTOMAKE_OPTIONS
> > in that directory's Makefile.am?
> Yes, this works.  Sorry for not having looked at the manual
> carefully enough (not that I did not try).
Well, I think it's not your fault: that option should be at least 
mentioned in the "Dependency Tracking" section.  This can probably be 
seen as a documentation bug.  Maybe I'll attempt a patch later or 
tomorrow.

Regards,
   Stefano

Re: Testing a new compiler with Automake "simple tests"

[Roberto Bagnara]

On 08/17/10 13:26, Stefano Lattarini wrote:

At Tuesday 17 August 2010, Roberto Bagnara wrote:

I would like to test a new special-purpose compiler
(which is part of a bigger project) using the Automake
"simple tests" feature.

I have two problems:

1) I have not found a way to force recompilation
 of all test programs whenever the compiler executable
 has changed.  Note that we are talking about
 thousands of test programs so, if at all possible,
 I would like to avoid listing that dependency
 for each one of those.

Maybe I don't understand the problem, but... what's wrong
with:
   $(TESTS): your-special-purpose-compiler
or something similar?


Hi Stefano, thanks for your prompt reply.
That dependency cases relinking whenever the compiler
changes, whereas I need recompilation.
Do you know if there is a way I can force Automake
to add a dependency on the compiler in the .c.o rule?
That is, to generate:

.c.o:   my-special-purpose-compiler
$(AM_V_CC) \
$(COMPILE) -c $<


2) Automatic dependency tracking cannot work in
 that directory of the project (indeed, the only
 dependency is on the compiler... all the test
 programs are self-contained).  How can I disably
 automatic dependency tracking *only* on that
 directory?

What about adding `no-dependencies' to AUTOMAKE_OPTIONS
in that directory's Makefile.am?  The documentation at

reads:
   "no-dependencies: This is similar to using --ignore-deps on the
command line, but is useful for those situations where you don't
have the necessary bits to make automatic dependency tracking work
(see Dependencies).  In this case the effect is to effectively
disable automatic dependency tracking."


Yes, this works.  Sorry for not having looked at the manual carefully
enough (not that I did not try).
Thanks a lot,

  Roberto

--
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it

Re: Testing a new compiler with Automake "simple tests"

[Stefano Lattarini]

At Tuesday 17 August 2010, Roberto Bagnara wrote:
> I would like to test a new special-purpose compiler
> (which is part of a bigger project) using the Automake
> "simple tests" feature.
>
> I have two problems:
> 
> 1) I have not found a way to force recompilation
> of all test programs whenever the compiler executable
> has changed.  Note that we are talking about
> thousands of test programs so, if at all possible,
> I would like to avoid listing that dependency
> for each one of those.
Maybe I don't understand the problem, but... what's wrong
with:
  $(TESTS): your-special-purpose-compiler
or something similar?

> 2) Automatic dependency tracking cannot work in
> that directory of the project (indeed, the only
> dependency is on the compiler... all the test
> programs are self-contained).  How can I disably
> automatic dependency tracking *only* on that
> directory?
What about adding `no-dependencies' to AUTOMAKE_OPTIONS
in that directory's Makefile.am?  The documentation at

reads:
  "no-dependencies: This is similar to using --ignore-deps on the
   command line, but is useful for those situations where you don't
   have the necessary bits to make automatic dependency tracking work
   (see Dependencies).  In this case the effect is to effectively
   disable automatic dependency tracking."

HTH,
  Stefano

Testing a new compiler with Automake "simple tests"

[Roberto Bagnara]

I would like to test a new special-purpose compiler
(which is part of a bigger project) using the Automake
"simple tests" feature.  I have two problems:

1) I have not found a way to force recompilation
   of all test programs whenever the compiler executable
   has changed.  Note that we are talking about
   thousands of test programs so, if at all possible,
   I would like to avoid listing that dependency
   for each one of those.

2) Automatic dependency tracking cannot work in
   that directory of the project (indeed, the only
   dependency is on the compiler... all the test
   programs are self-contained).  How can I disably
   automatic dependency tracking *only* on that
   directory?

Many thanks in advance,

   Roberto

--
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it

Re: RE : call for help/crazy idea: nmake sup port

[Peter Rosin]

Den 2010-08-13 19:18 skrev Ralf Wildenhues:
> I would like to thank everyone who provided input on this topic.
> It certainly helps when considering where to go.  One conclusion
> from this is that we should get Peter's MSVC support finished
> and completed for Automake 1.12 and the next Libtool release.
> 
> I wasn't aware that there are more MSVC-related build system tools
> which one could target.  I'm still not sure whether the idea to
> produce support for some of them should be buried completely, but
> I for one won't be pursuing it in the nearer future.  If somebody
> else feels scratching that it however ...
> 
> And of course I would be delighted if some of you provided fixes
> for pkg-config and whetever else is needed to make building for
> this setup work better.

Hi!

Sorry for the late reply.

A couple of things were never mentioned in this thread...

First I want to clarify that nmake support is not the same as
Visual Studio project file support. The project file can be used
to generate an nmake Makefile, but that is not "normal usage".
Normally you just load the project file into the GUI and go.
I don't know if there were anybody who had this wrong, I'm just
spelling it out just in case...

And second, in my opinion it is more important to not require
GNU binutils when using the MS toolchain, than to not require
a sensible make. We are almost there, but not completely. The
reasoning is that the make implementation should not affect the
end result, but mixing in tools from GNU binutils might. Most
of the remaining required uses of GNU binutils are not actually
doing anything to the binaries, they simply inspects them, but
one exception is the resource compiler.

This is an issue where automake could possibly help, since
Microsoft rc isn't really interface compatible with windres.
Microsoft rc produces a .res file, while GNU windres produces
a .obj (or .o) file. There's also the inevitable shuffle of
options... In a project of mine I have this in my
configure.ac:

AC_CHECK_TOOL(RC, windres,)
AC_ARG_VAR(RC, [Resource Compiler for Windows resources])
RC_VERSION

case $RC in
[[rR][cC]]*) msrc=yes ;;
*) msrc=no ;;
esac
AM_CONDITIONAL(HAVE_MSRC, test $msrc = yes)


And this in my Makefile.am:

if HAVE_WIN32RES
if HAVE_MSRC
foo_LDADD += foo.res
else
foo_LDADD += foo.$(OBJEXT)
endif
endif

if HAVE_MSRC
foo.res: foo.rc foo.ico src/resource.h
$(RC) -i $(top_srcdir)/src foo.rc
else
foo.o: foo.rc foo.ico src/resource.h
$(RC) --include-dir $(top_srcdir)/src foo.rc $@

foo.obj: foo.rc foo.ico src/resource.h
$(RC) --include-dir $(top_srcdir)/src foo.rc $@
endif


I would love to simplify that. I expect similar issues with
the message compiler (Microsoft mc vs. GNU windmc) but I haven't
needed a message compiler so I can't say...

Cheers,
Peter