> >> 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.
Sorry, I misunderstood what you wrote. Now I understood.
> >> 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.
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.
>
> 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?
I guess taking time to keep config.h up-to-date is very annoying
task.
> >> 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.
Signed-off-by: Masatake YAMATO <[EMAIL PROTECTED]>
diff --git a/Makefile b/Makefile
index 6f0e4c1..b01ca1b 100644
--- a/Makefile
+++ b/Makefile
@@ -60,7 +60,6 @@ install: all
@$(MAKE) -C lib install
@$(MAKE) -C include install
@$(MAKE) -C pan install
- @$(MAKE) -C m4 install
@$(MAKE) -C doc/man1 install
@$(MAKE) -C doc/man3 install
-------------------------------------------------------------------------
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
