Carmelo AMOROSO wrote: > Denys Vlasenko wrote: >> On Wednesday 04 March 2009 04:41:41 pm Salvatore CRO' wrote: >>> Hi Carmelo, >>> Attached is a proposal tailored for rpc test that could be very easily >>> extedend to all tests in uClibc. Indeed it avoids "include ../../.config" in >>> test Makefile by : >>> >>> - creating a new file Makefile.in with the same contents of existing >>> Makefile but "include ../Test.mak" >>> - replacing existing Makefile by a new one that only does some includes, >>> first one being "include ../Rules.mak" (that in turns got "include >>> ../../.config"), then includes the new Makefile.in and finally ../Test.mak >>> - removing "include ../Rules.mak" from ../Test.mak, since we've just done >>> it in Makefile. >>> >>> By including ../Rules.mak first, we ensure that _actual_ UCLIBC_HAS_xxx >>> values (through ../../.config) get evaluated by Makefile.in to arrange the >>> TESTS variable so that all due sources are correctly compiled. >>> >>> Using this approach, Makefile is the same for all tests and contains include >>> statements only while all test-specific settings lie in the new Makefile.in >> The cure seems to be worse than the disease: > >> # diffstat z >> Test.mak | 3 --- >> rpc/Makefile | 11 +++-------- >> rpc/Makefile.in | 11 +++++++++++ >> 3 files changed, 14 insertions(+), 11 deletions(-) > >> and this includes creation of a new file. > > I don't care about the amount of changes if the final solution is more > "elegant"... that's only a my opinion. > We have the same design in the libc with Makefile/Makefile.in couple. > > Further, unsing -include Makefile.in, you don't need to add any > Makefile.in if not needed (i.e. no reason for using TESTS :=, or > TESTS_DISABLED and so on). > Further current solution is more error prone because you may erroneously > include ../Test.mak too early in the Makefile. With the solution > proposed you keep all the common in the Makefile and the specific, if > needed in the Makefile.in. >> Why you can't just add one line, "include ../../.config", instead? >> -- >> vda > > > Carmelo >
Has some other any objections against this design ? Carmelo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
