Thank you for feed back. I've wanted about this patch. > ugh, this is not the way we want to take autotool integration. it is > supposed to be optional, not required.
I didn't want to rework on all Makefiles of LTP, too big task for me. It takes much time; and It affects all of LTP. So I introduced autotool very limited way. After making more testcases using autoconf, we can think about using autoconf to generate Makefiles. I'm not sure I can do it well now. However, a patch is welcome always. > clean is not supposed to imply distclean. if it did, what is the > point of distclean ? You are really right. See my first proposal patch: < +dist-clean: clean ac-dist-clean < + @$(MAKE) -C include $@ I didn't modify clean. I added dist-clean and made dist-clean depends on clean. I also wrote: < - dist-clean, a new make target, removes autom4te.cache, < config.log and config.status. < - maintainer-clean, a new make target, removes configure and < config.h.in. However, Subrata wrote: < clean is not supposed to imply distclean. if it did, what is the < point of distclean ? and the target is "distclean", not "dist-clean". So I replied: < > However, i wanted: < > make clean < > to do all that stuff. So, updated accordingly. < < I guess this will make people familiar with autoconf < confusing. Now you are confusing as I'm afraid. Please, talk to Subrata. I'm agree with you. > and the target is "distclean", not "dist-clean". You are right. Thank you. > if the user does not run configure, then we default to "latest sane > settings". if user wishes to compile on any other system, then they > have to go through the configure process. Sorry but I don't understood what you say. Could you tell me more? Are you talking about cross compiling? My patch doesn't take cross compiling into account. Even non-cross compiling, I was not sure my patch is good enough. If you have a trouble in cross compiling, tell me more or send a patch to this list. As you may know, in my patch configure is run from make. configure is run if *.m4, configure.ac and file is modified. "if user wishes to compile on any other system, then they have to go through the configure process". I don't understood what you want to say here. I think "Going through the configure process" is good thing. Do you think so or not? If the one want to build ltp on different systems, s/he should run configure for each time. > why do you install the m4 files ? they dont make any sense outside of > the build tree ... Good point. I wrote: < Further more we can separate ltp to the run time test and the build < time test. Currently we are interested in the run time. However, if we < introduce autoconf carefully, our configure macro set may be product; < it will be resalable on applications on GNU/Linux. < < Introducing autoconf may be big job. So we have to find something < incremental way for introducing. Installed ltp-signalfd.m4 may be useful when I want to write an application which uses signalfd syscall. ltp-signalfd.m4 will be well tested by ltp people, who are very interested in kernel/userland interface. Application developers may want to use such m4 macros. However, if you care about the size of installed files, I will provide another target to install m4 files like `install-m4' separated from `install'. Masatake YAMATO ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
