On Wednesday 14 January 2009 07:03:53 Masatake YAMATO wrote: > > On Wednesday 14 January 2009 04:09:16 Masatake YAMATO wrote: > > > > yes, there has been too much "put all CPPFLAGS into CFLAGS and dont > > > > use CPPFLAGS" in the tree. it isnt a critical issue, but one we > > > > should be fixing as we go rather than introducing more of the same. > > > > > > > > as for LOADLIBES vs LDLIBS, i believe the difference is that > > > > LOADLIBES are local libraries (i.e. static archives from the package > > > > -- liblta.a) while LDLIBS are external libraries (i.e. things like > > > > -lrt or -lcap or ...). but that might be more my opinion than > > > > reality :). i'm happy as long as one of those variables is being > > > > used instead of LDFLAGS. > > > > > > Could you write down these conversions used in LTP to toplevel Makefile > > > or somewhere? I was confused CFLAGS and CPPFLAGS. > > > > the conventions enforced are the standard ones. LTP isnt redefining any > > of the flags from their normal meaning. here's a quick summary off the > > top of my head: > > CFLAGS - used when compiling/linking C code (no CPPFLAGS!) > > CXXFLAGS - used when compiling/linking C++ code (no CPPFLAGS!) > > CPPFLAGS - used when preprocessor is run (so C/C++ compiling an $(CPP) > > checks) LDFLAGS - linker flags (no libraries) used when linking > > LDLIBS - libraries listed after objects during link > > > > i imagine the gcc manual has a definition for preprocessor flags, but the > > general usage is all -I/-D/-U flags. there are also a few more flags > > (like the -std= one) that should be in CPPFLAGS rather than > > CFLAGS/CXXFLAGS, but those dont come up too often. > > Thank you. I hope this is written in top level Makefile.
i guess it would be easy enough to document there > As far as testcases/kernel/syscalls, CPPFLAGS is not used widely. > Following command line prints nothing. > > $ cd ltp-git/testcases/kernel/syscalls/; > $ find . -type f -name '*.[ch]' -print0 | xargs -0 -e grep -nH -e > CPPFLAGS > > What should we do? right, that's why i suggested we simply fix as we go. it isnt a critical issue and most of the times, things will continue to "just work". -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
