On Wed, Nov 12, 2008 at 10:37 PM, Masatake YAMATO wrote: >> 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.
i dont think so. we're adding autoconf because of its ability to do header / library detection and because it's optional. i dont see the point of integrating automake. we assume GNU make which means most of the reasons for using automake is pointless. so until there's a real reason for requiring automake, we arent going to. >> 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. ive changed the system so now clean and distclean act like "standard" build systems (and like any autotooled system). clean will remove generated files that can be generated again by doing `make` while distclean will remove all files that require a `./configure ; make` type step. >> 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. ive committed the changes to cvs. there is a default config.h that targets an up-to-date Linux / POSIX system. if you run `make`, that is used. if you are building on any other system and you dont want a build failure, use `./configure ; make`. cross-compiling doesnt really matter here. >> 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'. i guess ... i dont think we should spend too much time targeting this audience as i doubt we'd get much real use. there's also a glut out there of m4 libraries, so it isnt like we'd be adding too much to the field. if people writing m4's really want to do this, then that's their business, but it shouldnt be a requirement here. assuming the m4 will only be used inside of the LTP build tree should make things easier. -mike ------------------------------------------------------------------------- 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
