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
> 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
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 r
> "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
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
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
* 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
> docu
[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
* 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 Mak
[ 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, precis
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 name
* 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
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
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 =
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.
> >
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
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 whenev
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 tal
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 re
19 matches
Mail list logo
