On Thu, Nov 13, 2008 at 12:14 AM, Masatake YAMATO wrote: >> 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. > > I read the changes and I understood the intent. > Which platform, version of kernel and architecture will we use to generate > "default" config.h? And who will do it? Will you do?
LTP is for Linux, so the default is Linux. arch hasnt been a real issue, and any test that needs to know the arch, then an autoconf test wont simplify it anyways. as for kernel / libc, i'd propose anything over a year old is fair game for assumption. ive documented this at the top of the config.h header. > I guess taking time to keep config.h up-to-date is very annoying > task. you dont have to it if you dont want to. running `./configure` will get you a "complete" config.h. >> >> 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. > > I see. Plesae, apply the following patch. > > --- a/Makefile > +++ b/Makefile > - @$(MAKE) -C m4 install we can leave it for now and see how things shake out -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
