Revising LTP Makefile infrastructure

[yaneurabeya]

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.
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.
3. The uclinux* make targets could be removed in favor of conditionally defined global targets.
   

     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.
Thanks,
-Garrett

PS I have no intention of using automake / autoconf. I find them to be somewhat atrocious build utilities :)...

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[Mike Frysinger]

On Wednesday 30 April 2008, Garrett Cooper wrote:
>    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.

multi-arch itself by definition is limiting.  adding any sort of magic in this
direction is just bloat.  i'd focus on out-of-tree building as that would
address any sort of random stuff people want to do.

>    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.

the gmake requirement has been unwritten so far ... might as well codify the
requirement and stop dancing around the issue.

>    3. The uclinux* make targets could be removed in favor of
>    conditionally defined global targets.

this is just a silly target.  i'd punt it.
-mike


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[Balbir Singh]

On Thu, May 1, 2008 at 8:44 AM, Mike Frysinger <vapier@...> wrote:

> On Wednesday 30 April 2008, Garrett Cooper wrote:
>  >    1. The make process isn't multiple arch/target friendly, i.e. you
>
> >    build once for x86 and you have to rebuiI am not sure about uclinux* targetsld for ia64, ppc64, etc and
>  > after the build capture all of the compiled binaries using some
>  > intermediary method.
>
>  multi-arch itself by definition is limiting.  adding any sort of magic in this
>  direction is just bloat.  i'd focus on out-of-tree building as that would
>  address any sort of random stuff people want to do.
>

I agree with you Mike, but I am curious to see what Garrett has,
specially if those cleanups are generic

>  >    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.
>
>  the gmake requirement has been unwritten so far ... might as well codify the
>  requirement and stop dancing around the issue.
>

The question basically boils down to -- can we use GNU make specific
features? My answer would be "Yes"

>  >    3. The uclinux* make targets could be removed in favor of
>  >    conditionally defined global targets.
>
>  this is just a silly target.  i'd punt it.
>  -mike

Balbir

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[Mike Frysinger]

On Tuesday 06 May 2008, Balbir Singh wrote:

> On Thu, May 1, 2008 at 8:44 AM, Mike Frysinger <vapier@...> wrote:
> > On Wednesday 30 April 2008, Garrett Cooper wrote:
> >  >    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.
> >
> >  the gmake requirement has been unwritten so far ... might as well codify
> > the requirement and stop dancing around the issue.
>
> The question basically boils down to -- can we use GNU make specific
> features? My answer would be "Yes"

sorry if i wasnt clear, but i was implying the same thing.  we already have
GNUisms in there and no one has complained, and it's trivial to install GNU
make on your system.
-mike


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[yaneurabeya]

On May 6, 2008, at 3:37 AM, Balbir Singh wrote:

> On Thu, May 1, 2008 at 8:44 AM, Mike Frysinger <vapier@...>  
> wrote:
>> On Wednesday 30 April 2008, Garrett Cooper wrote:
>>>   1. The make process isn't multiple arch/target friendly, i.e. you
>>
>>>   build once for x86 and you have to rebuiI am not sure about  
>>> uclinux* targetsld for ia64, ppc64, etc and
>>> after the build capture all of the compiled binaries using some
>>> intermediary method.
>>
>> multi-arch itself by definition is limiting.  adding any sort of  
>> magic in this
>> direction is just bloat.  i'd focus on out-of-tree building as that  
>> would
>> address any sort of random stuff people want to do.
>>
>
> I agree with you Mike, but I am curious to see what Garrett has,
> specially if those cleanups are generic
>
>>>   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.
>>
>> the gmake requirement has been unwritten so far ... might as well  
>> codify the
>> requirement and stop dancing around the issue.
>>
>
> The question basically boils down to -- can we use GNU make specific
> features? My answer would be "Yes"
>
>>>   3. The uclinux* make targets could be removed in favor of
>>>   conditionally defined global targets.
>>
>> this is just a silly target.  i'd punt it.
>> -mike
>
> Balbir

        The makefiles are mostly done (the top-level ones that LTP touches,  
i.e. not the ballista and other subproject makefiles as LTP isn't the  
maintainers and those should be fixed upstream), but there's some sort  
of misunderstanding on my part as to how define's and variable  
scoping, lifetime, and rule evaluation are done with GNU make(1) with  
include'd Makefiles, so I've punted the ball back up-court until I can  
get some helpful answers from them, as their documentation is slightly  
confusing.
        So far my diff is ~190KB large.
Cheers,
-Garrett

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[Subrata Modak]

On Mon, 2008-05-19 at 02:18 -0700, Garrett Cooper wrote:

> On May 6, 2008, at 3:37 AM, Balbir Singh wrote:
>
> > On Thu, May 1, 2008 at 8:44 AM, Mike Frysinger <vapier@...>  
> > wrote:
> >> On Wednesday 30 April 2008, Garrett Cooper wrote:
> >>>   1. The make process isn't multiple arch/target friendly, i.e. you
> >>
> >>>   build once for x86 and you have to rebuiI am not sure about  
> >>> uclinux* targetsld for ia64, ppc64, etc and
> >>> after the build capture all of the compiled binaries using some
> >>> intermediary method.
> >>
> >> multi-arch itself by definition is limiting.  adding any sort of  
> >> magic in this
> >> direction is just bloat.  i'd focus on out-of-tree building as that  
> >> would
> >> address any sort of random stuff people want to do.
> >>
> >
> > I agree with you Mike, but I am curious to see what Garrett has,
> > specially if those cleanups are generic
> >
> >>>   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.
> >>
> >> the gmake requirement has been unwritten so far ... might as well  
> >> codify the
> >> requirement and stop dancing around the issue.
> >>
> >
> > The question basically boils down to -- can we use GNU make specific
> > features? My answer would be "Yes"
> >
> >>>   3. The uclinux* make targets could be removed in favor of
> >>>   conditionally defined global targets.
> >>
> >> this is just a silly target.  i'd punt it.
> >> -mike
> >
> > Balbir
>
> The makefiles are mostly done (the top-level ones that LTP touches,  
> i.e. not the ballista and other subproject makefiles as LTP isn't the  
> maintainers and those should be fixed upstream), but there's some sort  
> of misunderstanding on my part as to how define's and variable  
> scoping, lifetime, and rule evaluation are done with GNU make(1) with  
> include'd Makefiles, so I've punted the ball back up-court until I can  
> get some helpful answers from them, as their documentation is slightly  
> confusing.
> So far my diff is ~190KB large.

Good to know that. Please also include a very good documentation on what
the forthcoming patch will address in LTP Makefiles. We are looking for
a good debate and final inclusion.

Regards--
Subrata

> Cheers,
> -Garrett
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@...
> https://lists.sourceforge.net/lists/listinfo/ltp-list

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[nate-ltp]

On May 19 02:18, Garrett Cooper wrote:
> The makefiles are mostly done (the top-level ones that LTP touches,  
> i.e. not the ballista and other subproject makefiles as LTP isn't the  
> maintainers and those should be fixed upstream), but there's some sort  
> of misunderstanding on my part as to how define's and variable  
> scoping, lifetime, and rule evaluation are done with GNU make(1) with  
> include'd Makefiles, so I've punted the ball back up-court until I can  
> get some helpful answers from them, as their documentation is slightly  
> confusing.

Are you converting to a non-recursive build?  I made the transition
in one of my projects and there were a few things to keep in mind.  
 1. All variables are global and can get overwritten in includes.
 2. It's best to do everything before including the next makefile.
 3. Target-specific variables are the best thing since sliced bread.

I'd be willing to look at your patch and try to resolve the confusion
you're having.

> So far my diff is ~190KB large.

Is that all?  ;)

Nate

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[Subrata Modak]

On Mon, 2008-05-19 at 09:43 -0400, Nate Straz wrote:

> On May 19 02:18, Garrett Cooper wrote:
> > The makefiles are mostly done (the top-level ones that LTP touches,  
> > i.e. not the ballista and other subproject makefiles as LTP isn't the  
> > maintainers and those should be fixed upstream), but there's some sort  
> > of misunderstanding on my part as to how define's and variable  
> > scoping, lifetime, and rule evaluation are done with GNU make(1) with  
> > include'd Makefiles, so I've punted the ball back up-court until I can  
> > get some helpful answers from them, as their documentation is slightly  
> > confusing.
>
> Are you converting to a non-recursive build?  I made the transition
> in one of my projects and there were a few things to keep in mind.  
>  1. All variables are global and can get overwritten in includes.
>  2. It's best to do everything before including the next makefile.
>  3. Target-specific variables are the best thing since sliced bread.
>
> I'd be willing to look at your patch and try to resolve the confusion
> you're having.

Nate,

I am happy that you will be reviewing it.

Garrett,

I would like to have a very good document highlighting the changes and
their benefits.

Regards--
Subrata

>
> > So far my diff is ~190KB large.
>
> Is that all?  ;)
>
> Nate
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@...
> https://lists.sourceforge.net/lists/listinfo/ltp-list

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[yaneurabeya]

On May 19, 2008, at 6:49 AM, Subrata Modak wrote:

> On Mon, 2008-05-19 at 09:43 -0400, Nate Straz wrote:
>> On May 19 02:18, Garrett Cooper wrote:
>>> The makefiles are mostly done (the top-level ones that LTP touches,
>>> i.e. not the ballista and other subproject makefiles as LTP isn't  
>>> the
>>> maintainers and those should be fixed upstream), but there's some  
>>> sort
>>> of misunderstanding on my part as to how define's and variable
>>> scoping, lifetime, and rule evaluation are done with GNU make(1)  
>>> with
>>> include'd Makefiles, so I've punted the ball back up-court until I  
>>> can
>>> get some helpful answers from them, as their documentation is  
>>> slightly
>>> confusing.
>>
>> Are you converting to a non-recursive build?  I made the transition
>> in one of my projects and there were a few things to keep in mind.
>> 1. All variables are global and can get overwritten in includes.
>> 2. It's best to do everything before including the next makefile.
>> 3. Target-specific variables are the best thing since sliced bread.
>>
>> I'd be willing to look at your patch and try to resolve the confusion
>> you're having.
>
> Nate,
>
> I am happy that you will be reviewing it.
>
> Garrett,
>
> I would like to have a very good document highlighting the changes and
> their benefits.
>
> Regards--
> Subrata
>
>>
>>> So far my diff is ~190KB large.
>>
>> Is that all?  ;)
>>
>> Nate

        I haven't gotten all of the changes done yet, so this effort is most  
likely going to carry over into next month. I'll try and keep up with  
changes in CVS and submit everything to you folks when it's to a point  
where it's mature and stable enough to be inserted into the LTP base.
        I ran into a few issues / concerns with some C source files though so  
I'll submit separate patches for those soon.
Thanks,
-Garrett

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[Subrata Modak]

On Thu, 2008-05-22 at 14:11 -0700, Garrett Cooper wrote:

> On May 19, 2008, at 6:49 AM, Subrata Modak wrote:
>
> > On Mon, 2008-05-19 at 09:43 -0400, Nate Straz wrote:
> >> On May 19 02:18, Garrett Cooper wrote:
> >>> The makefiles are mostly done (the top-level ones that LTP touches,
> >>> i.e. not the ballista and other subproject makefiles as LTP isn't  
> >>> the
> >>> maintainers and those should be fixed upstream), but there's some  
> >>> sort
> >>> of misunderstanding on my part as to how define's and variable
> >>> scoping, lifetime, and rule evaluation are done with GNU make(1)  
> >>> with
> >>> include'd Makefiles, so I've punted the ball back up-court until I  
> >>> can
> >>> get some helpful answers from them, as their documentation is  
> >>> slightly
> >>> confusing.
> >>
> >> Are you converting to a non-recursive build?  I made the transition
> >> in one of my projects and there were a few things to keep in mind.
> >> 1. All variables are global and can get overwritten in includes.
> >> 2. It's best to do everything before including the next makefile.
> >> 3. Target-specific variables are the best thing since sliced bread.
> >>
> >> I'd be willing to look at your patch and try to resolve the confusion
> >> you're having.
> >
> > Nate,
> >
> > I am happy that you will be reviewing it.
> >
> > Garrett,
> >
> > I would like to have a very good document highlighting the changes and
> > their benefits.
> >
> > Regards--
> > Subrata
> >
> >>
> >>> So far my diff is ~190KB large.
> >>
> >> Is that all?  ;)
> >>
> >> Nate
>
> I haven't gotten all of the changes done yet, so this effort is most  
> likely going to carry over into next month. I'll try and keep up with  

That is not an issue at all. Giving the effort you are putting in, it
would definitely take time. I am also of the opinion that you can
stabilize it on your part before pushing the same to LTP. Anyways we
will also have several rounds of review once that is in LTP. But it
would be nice if the first push itself is in good shape.

Regards--
Subrata

> changes in CVS and submit everything to you folks when it's to a point  
> where it's mature and stable enough to be inserted into the LTP base.
> I ran into a few issues / concerns with some C source files though so  
> I'll submit separate patches for those soon.
> Thanks,
> -Garrett


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[yaneurabeya]

On Tue, May 27, 2008 at 5:28 AM, Nate Straz <nate-ltp@...> wrote:

On May 27 02:46, Garrett Cooper wrote:

> My diff has grown a bit since I last spoke...

Which version of LTP is this patch against?

Nate

20080430. Found a few bugs and I'm resubmitting a new patch very soon...
-Garrett

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[yaneurabeya]

On Tue, May 27, 2008 at 3:58 PM, Garrett Cooper <yanegomi@...> wrote:

On Tue, May 27, 2008 at 5:28 AM, Nate Straz <nate-ltp@...> wrote:

On May 27 02:46, Garrett Cooper wrote:

> My diff has grown a bit since I last spoke...

Which version of LTP is this patch against?

Nate

20080430. Found a few bugs and I'm resubmitting a new patch very soon...
-Garrett

Try this patchset on for size: <http://gengplfoss.googlecode.com/files/ltp_makefiles_set2.patch.bz2>.
-Garrett

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[nate-ltp]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[Subrata Modak]

On Tue, 2008-05-27 at 16:32 -0700, Garrett Cooper wrote:

> On Tue, May 27, 2008 at 3:58 PM, Garrett Cooper <yanegomi@...>
> wrote:
>        
>         On Tue, May 27, 2008 at 5:28 AM, Nate Straz
>         <nate-ltp@...> wrote:
>                 On May 27 02:46, Garrett Cooper wrote:
>                
>                 > My diff has grown a bit since I last spoke...
>                
>                
>                 Which version of LTP is this patch against?
>                
>                 Nate
>        
>        
>        
>         20080430. Found a few bugs and I'm resubmitting a new patch
>         very soon...
>         -Garrett
>
> Try this patchset on for size:
> <http://gengplfoss.googlecode.com/files/ltp_makefiles_set2.patch.bz2>.
> -Garrett

Garrett,

Hope you are making good progress. Do you think we can push the stable
one in another 2 months time ?

Regards--
Subrata

> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list


-------------------------------------------------------------------------
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
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[yaneurabeya]

On Wed, Jun 18, 2008 at 8:41 AM, Subrata Modak
<subrata@...> wrote:

> On Tue, 2008-05-27 at 16:32 -0700, Garrett Cooper wrote:
>> On Tue, May 27, 2008 at 3:58 PM, Garrett Cooper <yanegomi@...>
>> wrote:
>>
>>         On Tue, May 27, 2008 at 5:28 AM, Nate Straz
>>         <nate-ltp@...> wrote:
>>                 On May 27 02:46, Garrett Cooper wrote:
>>
>>                 > My diff has grown a bit since I last spoke...
>>