Re: Testing a new compiler with Automake simple tests
On 08/18/10 20:34, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Wed, Aug 18, 2010 at 03:42:01PM CEST: On Wednesday 18 August 2010, Roberto Bagnara wrote: On 08/18/10 13:18, Stefano Lattarini wrote: At Wednesday 18 August 2010, Roberto Bagnara wrote: #$(TESTS:=...@objext@): ../../bin/compiler The above is rejected even with the dot. This seems like an automake limitation... no big deal though, as there is the simple workaround: TESTS_OBJS = $(TESTS:=...@objext@) $(TESTS_OBJS): ../../bin/compiler which is also clearer to read IMO. Yeah, that's just an automake parsing buglet. it's better to do: TESTS = t1 t2 t3 t4 t5 t6 TESTS_OBJS = $(t1_OBJECTS) $(t2_OBJECTS) $(t3_OBJECTS) \ $(t4_OBJECTS) $(t5_OBJECTS) $(t6_OBJECTS) $(TESTS_OBJS): ../../bin/compiler Unfortunately, this is more error-prone, since if you add, say, `t7' to TESTS, but forget to add $(t7_OBJECTS) to TESTS_OBJS, you'll have missing dependencies... Well, you'll decide what's better for you. Hmm, it is error-prone indeed. Moreover, we have more than one thousands tests and we could soon have two thousands of them. I suppose automake could be enhanced to also define $(OBJECTS) as the set of all objects. Yes, this would be a nice thing. But there are other ways you could hack around this. Iff your compiler is generated from a different Makefile.am (this is important!), then in the tests/Makefile.am you could: BUILT_SOURCES = stamp-objects stamp-objects: ../../bin/compiler -rm -f *.$(OBJEXT) -rm -f sub/*.$(OBJEXT) ... echo timestamp$@ It is rather hacky, but it should work. Untested. It works! Thanks, 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
Hello Ralf. On Wednesday 18 August 2010, Ralf Wildenhues wrote: I suppose automake could be enhanced to also define $(OBJECTS) as the set of all objects. What about libtool objects? Should we care about them? I'm writing a couple of (xfailing) testcases to check a prospective patch introducing $(OBJECTS) (BTW, is such a general name enough namespace-safe? I hardly think so...), and I don't know what to do for libtool objects. Regards, Stefano
Re: Testing a new compiler with Automake simple tests
* Stefano Lattarini wrote on Thu, Aug 19, 2010 at 04:39:29PM CEST: On Wednesday 18 August 2010, Ralf Wildenhues wrote: I suppose automake could be enhanced to also define $(OBJECTS) as the set of all objects. What about libtool objects? Should we care about them? I'm writing a couple of (xfailing) testcases to check a prospective patch introducing $(OBJECTS) (BTW, is such a general name enough namespace-safe? I hardly think so...), and I don't know what to do for libtool objects. At this point I'm not sure if it's safe or worthwhile to add either of them. This is a pretty special case here, and we don't really have much use for this otherwise, do we? Generally, I think the idea a couple of years ago was to move away from the all-collecting variables such as $(SOURCES), $(PROGRAMS) etc. Haven't dug history to find out for sure why, though. Cheers, Ralf
Re: Testing a new compiler with Automake simple tests
On Thursday 19 August 2010, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Thu, Aug 19, 2010 at 04:39:29PM CEST: On Wednesday 18 August 2010, Ralf Wildenhues wrote: I suppose automake could be enhanced to also define $(OBJECTS) as the set of all objects. What about libtool objects? Should we care about them? I'm writing a couple of (xfailing) testcases to check a prospective patch introducing $(OBJECTS) (BTW, is such a general name enough namespace-safe? I hardly think so...), and I don't know what to do for libtool objects. At this point I'm not sure if it's safe or worthwhile to add either of them. This is a pretty special case here, and we don't really have much use for this otherwise, do we? Generally, I think the idea a couple of years ago was to move away from the all-collecting variables such as $(SOURCES), $(PROGRAMS) etc. Haven't dug history to find out for sure why, though. Agreed. I'll let the testcases I've written committed to a local branch, just in case. Regards, Stefano
Re: Testing a new compiler with Automake simple tests
On 08/17/2010 08:47 PM, Ralf Wildenhues wrote: * 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. Dear Stefano and Ralf, thank you very much for your assistance. I am a bit confused; here is what I have in my Makefile.am # This does not work: Automake 1.11 rejects it with # Makefile.am:1148: bad characters in variable name `$(TESTS' #$(TESTS:=...@objext@): ../../bin/compiler # This does not work: when ../../bin/compiler changes, tests are not recompiled. #TESTS_OBJS = $(TESTS:=...@objext@) #$(TESTS_OBJS): ../../bin/compiler # This works (but is nonportable and has several other problems). TESTS_OBJS = $(TESTS:=.o) $(TESTS_OBJS): ../../bin/compiler I am sure I am missing something obvious... All the best, 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
At Wednesday 18 August 2010, Roberto Bagnara wrote: Dear Stefano and Ralf, thank you very much for your assistance. I am a bit confused; here is what I have in my Makefile.am # This does not work: Automake 1.11 rejects it with # Makefile.am:1148: bad characters in variable name `$(TESTS' #$(TESTS:=...@objext@): ../../bin/compiler # This does not work: when ../../bin/compiler changes, tests are # not recompiled. # TESTS_OBJS = $(TESTS:=...@objext@) Typo here (and in Ralf example): should be $(TESTS:=...@objext@), with a dot `.' before @OBJEXT@ (this is because @OBJEXT@ do not contain a leading dot: it's either `o' or `obj'). # $(TESTS_OBJS): ../../bin/compiler That said, you should consider Ralf's suggestion to use the $(*_OBJECTS) variables instead, for more correctness. In fact, as Ralf pointed out in a previous message: ... 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) KR support, and others. So, instead of doing simply e.g.: TESTS = t1 t2 t3 t4 t5 t6 TESTS_OBJS = $(TESTS:=...@objext@) $(TESTS_OBJS): ../../bin/compiler it's better to do: TESTS = t1 t2 t3 t4 t5 t6 TESTS_OBJS = $(t1_OBJECTS) $(t2_OBJECTS) $(t3_OBJECTS) \ $(t4_OBJECTS) $(t5_OBJECTS) $(t6_OBJECTS) $(TESTS_OBJS): ../../bin/compiler Unfortunately, this is more error-prone, since if you add, say, `t7' to TESTS, but forget to add $(t7_OBJECTS) to TESTS_OBJS, you'll have missing dependencies... Well, you'll decide what's better for you. HTH, Stefano
Re: Testing a new compiler with Automake simple tests
On 08/18/10 13:18, Stefano Lattarini wrote: At Wednesday 18 August 2010, Roberto Bagnara wrote: # This does not work: when ../../bin/compiler changes, tests are # not recompiled. # TESTS_OBJS = $(TESTS:=...@objext@) Typo here (and in Ralf example): should be $(TESTS:=...@objext@), with a dot `.' before @OBJEXT@ (this is because @OBJEXT@ do not contain a leading dot: it's either `o' or `obj'). Ah, right. # This does not work: Automake 1.11 rejects it with # Makefile.am:1148: bad characters in variable name `$(TESTS' #$(TESTS:=...@objext@): ../../bin/compiler The above is rejected even with the dot. That said, you should consider Ralf's suggestion to use the $(*_OBJECTS) variables instead, for more correctness. In fact, as Ralf pointed out in a previous message: ... 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) KR support, and others. So, instead of doing simply e.g.: TESTS = t1 t2 t3 t4 t5 t6 TESTS_OBJS = $(TESTS:=...@objext@) $(TESTS_OBJS): ../../bin/compiler it's better to do: TESTS = t1 t2 t3 t4 t5 t6 TESTS_OBJS = $(t1_OBJECTS) $(t2_OBJECTS) $(t3_OBJECTS) \ $(t4_OBJECTS) $(t5_OBJECTS) $(t6_OBJECTS) $(TESTS_OBJS): ../../bin/compiler Unfortunately, this is more error-prone, since if you add, say, `t7' to TESTS, but forget to add $(t7_OBJECTS) to TESTS_OBJS, you'll have missing dependencies... Well, you'll decide what's better for you. Hmm, it is error-prone indeed. Moreover, we have more than one thousands tests and we could soon have two thousands of them. Said that, I will probably use this solution. For the long term, given that the problem I am facing seems rather general (testing compilers or compiler-like tools), would you consider the possibility to extend Automate to simplify the job? 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
On Wednesday 18 August 2010, Roberto Bagnara wrote: On 08/18/10 13:18, Stefano Lattarini wrote: At Wednesday 18 August 2010, Roberto Bagnara wrote: # This does not work: when ../../bin/compiler changes, tests are # not recompiled. # TESTS_OBJS = $(TESTS:=...@objext@) Typo here (and in Ralf example): should be $(TESTS:=...@objext@), with a dot `.' before @OBJEXT@ (this is because @OBJEXT@ do not contain a leading dot: it's either `o' or `obj'). Ah, right. # This does not work: Automake 1.11 rejects it with # Makefile.am:1148: bad characters in variable name `$(TESTS' #$(TESTS:=...@objext@): ../../bin/compiler The above is rejected even with the dot. This seems like an automake limitation... no big deal though, as there is the simple workaround: TESTS_OBJS = $(TESTS:=...@objext@) $(TESTS_OBJS): ../../bin/compiler which is also clearer to read IMO. That said, you should consider Ralf's suggestion to use the $(*_OBJECTS) variables instead, for more correctness. In fact, as Ralf pointed out in a previous message: ... 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) KR support, and others. So, instead of doing simply e.g.: TESTS = t1 t2 t3 t4 t5 t6 TESTS_OBJS = $(TESTS:=...@objext@) $(TESTS_OBJS): ../../bin/compiler it's better to do: TESTS = t1 t2 t3 t4 t5 t6 TESTS_OBJS = $(t1_OBJECTS) $(t2_OBJECTS) $(t3_OBJECTS) \ $(t4_OBJECTS) $(t5_OBJECTS) $(t6_OBJECTS) $(TESTS_OBJS): ../../bin/compiler Unfortunately, this is more error-prone, since if you add, say, `t7' to TESTS, but forget to add $(t7_OBJECTS) to TESTS_OBJS, you'll have missing dependencies... Well, you'll decide what's better for you. Hmm, it is error-prone indeed. Moreover, we have more than one thousands tests and we could soon have two thousands of them. Said that, I will probably use this solution. Well, you can always add a bit of indirection, and make the content of $(TESTS_OBJS) auto-generated. You can take a look at how Automake's own `tests/Makefile.am' does something similar to generate the content of the `$(parallel_tests)' variable. For the long term, given that the problem I am facing seems rather general (testing compilers or compiler-like tools), would you consider the possibility to extend Automate to simplify the job? I think I definitely lack the insight and experience to get this right. Let's wait what Ralf has to say about it... apart from Patches are always welcome, obviously ;-) Regards, Stefano
Re: Testing a new compiler with Automake simple tests
* Stefano Lattarini wrote on Wed, Aug 18, 2010 at 03:42:01PM CEST: On Wednesday 18 August 2010, Roberto Bagnara wrote: On 08/18/10 13:18, Stefano Lattarini wrote: At Wednesday 18 August 2010, Roberto Bagnara wrote: #$(TESTS:=...@objext@): ../../bin/compiler The above is rejected even with the dot. This seems like an automake limitation... no big deal though, as there is the simple workaround: TESTS_OBJS = $(TESTS:=...@objext@) $(TESTS_OBJS): ../../bin/compiler which is also clearer to read IMO. Yeah, that's just an automake parsing buglet. it's better to do: TESTS = t1 t2 t3 t4 t5 t6 TESTS_OBJS = $(t1_OBJECTS) $(t2_OBJECTS) $(t3_OBJECTS) \ $(t4_OBJECTS) $(t5_OBJECTS) $(t6_OBJECTS) $(TESTS_OBJS): ../../bin/compiler Unfortunately, this is more error-prone, since if you add, say, `t7' to TESTS, but forget to add $(t7_OBJECTS) to TESTS_OBJS, you'll have missing dependencies... Well, you'll decide what's better for you. Hmm, it is error-prone indeed. Moreover, we have more than one thousands tests and we could soon have two thousands of them. I suppose automake could be enhanced to also define $(OBJECTS) as the set of all objects. But there are other ways you could hack around this. Iff your compiler is generated from a different Makefile.am (this is important!), then in the tests/Makefile.am you could: BUILT_SOURCES = stamp-objects stamp-objects: ../../bin/compiler -rm -f *.$(OBJEXT) -rm -f sub/*.$(OBJEXT) ... echo timestamp $@ It is rather hacky, but it should work. Untested. Cheers, Ralf
Re: Testing a new compiler with Automake simple tests
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 http://www.gnu.org/software/automake/manual/automake.html#Options 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
Re: Testing a new compiler with Automake simple tests
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 http://www.gnu.org/software/automake/manual/automake.html#Options 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
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
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
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
* 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
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
* 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
Re: Testing a new compiler with Automake simple tests
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
