On Jun 18 09:31, Garrett Cooper wrote: > On Wed, Jun 18, 2008 at 8:41 AM, Subrata Modak > > Hope you are making good progress. Do you think we can push the stable > > one in another 2 months time ? > > I've submitted quite a few revised patches to Nate though and I still > have a fair amount of work to go with some of the modules, but it > should be completed -- first draft -- at the end of this month
I sent out a few questions which I think I only sent to the list instead of cc'ing you on. Here they are again. On May 27 02:46, Garrett Cooper wrote: > Keeping with the FLOSS analog, I want to build up commentary so I > don't go off too far in the wrong direction.. A good idea because this is already a giant patch. > This is a first run at the changes I'm making to the Makefiles. A few > notes: > > 1. Some components are broken. FILTER_OUT_DIRS will key you into > what's missing / not working, 9 times out of 10, and I tried to > comment where there were issues. This breakage should be fixed by next > "patch release". This is totally expected with a change of this scope. LTP is a huge project. In ltp-full-20080430 there are 630 Makefiles. > 2. MAKE_TARGETS is required for all inclusions right now. I tried > pushing it into master_rules.mk, but it didn't work. Then again I'm > not a GNU Make pro, so... I noticed that you had a .DEFAULT_GOAL as a rule instead of a variable in master_rules.mk. The line should look like this: .DEFAULT_GOAL := all > 3. I'm moving all relevant libs that can be separated out into lib, > and moving all scripts into scripts, just to better sort out everything. That sounds like a good plan. Although doing this as a separate step from the makefile rewrite would make it easier to review. > 4. hugemap's libipc is broken. I'm fixing that up with a revised diff > soon. > 5. libipc is being sorted out into libipc_core, libipc_hugemap, and > libipc_syscall, based on analysis of the code in testcases/kernel/ > syscall/ipc/lib and testcases/kernel/hugemap/lib. > 6. lib/ltp/tst_kvercmp.c didn't stick to standard conventions with > exit codes and was erroring out on me when I was trying to compile > things. So, I fixed up the macros a bit and now it works like it > should. That file should be revised as well to become arch independent. > 7. I'm using $(srcdir) to specify the source directory, $(prefix) for > the install prefix, $(srcdir)/lib for placing the static libs. > 8. About the .mk files: > a. config.mk contains a number of important variables. All stuff > that isn't meant to be touched is prefixed with "__". > b. compiler_detect.mk contains compiler detection items. This helps > when trying to determine what target host one's building for, and in > the future what arguments should be specified for $(CC), etc. Someone with cross-compiler experience will have to review compiler_detect.mk and target_detect.mk. > c. master_rules.mk contains a number of master Makefile rules. > i. __generic_bin is used for generic binaries (the leaf > building target). You need to specify MAKE_TARGETS for this > one (hopefully > this will be fixed in the next "patch release"). > ii. __generic_dir is used for generic directories. You can > specify what dirs you don't want to include with > FILTER_OUT_DIRS and you > can specify what directories you want to include with SUBDIRS. I was > thinking of doing an analog like FILTER_DIRS, but if one goes to great > lengths to do that, they could always just remake the __get_make_dirs > macro. > iii. __testcases_generic_bin is an extension of > __generic_bin to set $(prefix) to $(srcdir)/testcases/bin. > Just trying to > reduce duplicated text. > iv. __testcases_kernel_syscalls should probably be tossed > since it's the same thing as __testcases_generic_bin. In 8a you talk about not touching anything that starts with __, but here to define stuff to be used which starts with __. I think you should name these defines in a way that shows they are makefile templates. > 9. Standardizing variables: > a. -L arguments are specified in LDFLAGS. > b. -l (L) arguments are specified in LOADLIBES. > c. -I (i) arguments are specified with CPPFLAGS. This might need > revising (should this be with CFLAGS?)... CPPFLAGS are for C++ compliles. I didn't think we had anything in LTP that was written in C++. > 10. install(1) is being used instead of ln(1). It just makes more > sense (for me) that way. Sounds good. > 11. The make operation is recursive, so make(1) includes Makefile.inc > files in current work directory all the way up the tree, until the > top. The logic should be along the lines: > > rootpath ?= . > rootpath := $(rootpath)/.. > > include $(rootpath)/Makefile.inc So it's recursive on the way down and crawls back up for each Makefile too. Yikes! So instead of marking the depth in each makefile so it can find something in the root, you're scattering files in every directory so you can find the root still. A novel approach, but I think you'd be better off going completely non-recursive. > # Do all required logic here, like set variables, etc > > The recursive make(1) idea is a double edged sword: > Pro: > a. It's cool because it allows you to avoid duplicating > LOADLIBES inclusions, etc, and you can build up the make > process. That's funny. I thought that was an advantage of a non-recursive make. ;) > Cons: > a. A lot more files in the SCM. I would prefer if there were a way to collapse Makefile and Makefile.inc in each directory into one file. > b. Understanding where something at fault is coming from, > may be confusing... I think that's just a trait of make in general. The most helpful thing it to analyze the output of `make -p`. > 12. .../Makefile.inc had a bug in it. "sh -c 'MI=Makefile.inc; cp $MI > $MK.bk; sed -e 's/rootdir/rootpath/' < $MI.bk > $MI; rm $MI.bk'" would > fix that. sed now has an inplace flag, -i. I decided to look back at your original post. On Apr 30 19:17, Garrett Cooper wrote: > Hello, > It's me emailing again about attempting to improve the way that LTP is > built and tested. > As part of the validation of work with Cisco that I'm working on, it is > my responsibility to integrate LTP into our testing infrastructure. After > analyzing the Makefiles I've come to the following conclusions: > > 1. The make process isn't multiple arch/target friendly, i.e. you > build once for x86 and you have to rebuild for ia64, ppc64, etc and after > the build capture all of the compiled binaries using some intermediary > method. What parts of your patch address this point? Did you take into account Mike's suggestion of out-of-tree builds? > 2. Assuming that the user has gmake (which they should if they plan on > working with LTP and Linux), there are a number of simplifications that can > be made to the Makefiles to allow for simpler variable and make target > definition. Could you elaborate on the things you did you address this goal? > 3. The uclinux* make targets could be removed in favor of > conditionally defined global targets. I think your changes to limit the scope of the build when building for uclinux look good. > I am more than happy to complete all of the work and submit it to LTP, > but I need to know whether or not there is any interest from the LTP > community before going down that road too far. > > PS I have no intention of using automake / autoconf. I find them to be > somewhat atrocious build utilities :)... Thanks for digging into this. I know how long and hard a makefile rewrite can be. Luckily mine was only about 130 makefiles. Nate ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
