[LTP] LTP 20091031 Makefiles totally broken?!?

[LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

I ran configure, which seems to spend 99% of its time
checking for stuff that is always there on any Linux,
and after that I just get

# make
make: `testcases/realtime/configure' is up to date.
#

Can we please have the old Makefiles back? 

Thanks,

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 688 bytes --]

On Friday 06 November 2009 04:57:45 Andi Kleen wrote:
> I ran configure, which seems to spend 99% of its time
> checking for stuff that is always there on any Linux,

not really.  most of the configure checks are there because people have 
complained about specific issues trying to run on older linux distros.  and we 
arent actively blocking using LTP on other *nix systems.

> and after that I just get
> 
> # make
> make: `testcases/realtime/configure' is up to date.
> #

-ENEEDINFO

are you using live cvs ?  latest release ?  what distro ?  what version of 
autoconf/make ?  what does `make -d` show ?

> Can we please have the old Makefiles back?

no
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

On Fri, Nov 06, 2009 at 07:16:39AM -0400, Mike Frysinger wrote:
> On Friday 06 November 2009 04:57:45 Andi Kleen wrote:
> > I ran configure, which seems to spend 99% of its time
> > checking for stuff that is always there on any Linux,
> 
> not really.  most of the configure checks are there because people have 
> complained about specific issues trying to run on older linux distros.  and we 

I always just deleted the tests that didn't build. That's far better
than not building at all like now.

> arent actively blocking using LTP on other *nix systems.

yes you're just actively blocking running LTP on Linux now it seems.

> 
> > and after that I just get
> > 
> > # make
> > make: `testcases/realtime/configure' is up to date.
> > #
> 
> -ENEEDINFO
> 
> are you using live cvs ?  latest release ?  what distro ?  what version of 

See Subject on SUSE 10.0

> autoconf/make ?  what does `make -d` show ?

autoconf doesn't matter because I didn't regenerate the script.

GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `/root/ltp-full-20091031/include/mk/env_pre.mk' (search path) (no ~ expansion)...
Reading makefile `/root/ltp-full-20091031/include/mk/config.mk' (search path) (don't care) (no ~ expansion)...
Reading makefile `/root/ltp-full-20091031/include/mk/automake.mk' (search path) (no ~ expansion)...
Updating makefiles....
 Considering target file `/root/ltp-full-20091031/include/mk/automake.mk'.
  Looking for an implicit rule for `/root/ltp-full-20091031/include/mk/automake.mk'.
  Trying pattern rule with stem `automake.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/automake.mk,v'.
  Trying pattern rule with stem `automake.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/RCS/automake.mk,v'.
  Trying pattern rule with stem `automake.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/RCS/automake.mk'.
  Trying pattern rule with stem `automake.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/s.automake.mk'.
  Trying pattern rule with stem `automake.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/SCCS/s.automake.mk'.
  No implicit rule found for `/root/ltp-full-20091031/include/mk/automake.mk'.
  Finished prerequisites of target file `/root/ltp-full-20091031/include/mk/automake.mk'.
 No need to remake target `/root/ltp-full-20091031/include/mk/automake.mk'.
 Considering target file `/root/ltp-full-20091031/include/mk/config.mk'.
  Looking for an implicit rule for `/root/ltp-full-20091031/include/mk/config.mk'.
  Trying pattern rule with stem `config.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/config.mk,v'.
  Trying pattern rule with stem `config.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/RCS/config.mk,v'.
  Trying pattern rule with stem `config.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/RCS/config.mk'.
  Trying pattern rule with stem `config.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/s.config.mk'.
  Trying pattern rule with stem `config.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/SCCS/s.config.mk'.
  No implicit rule found for `/root/ltp-full-20091031/include/mk/config.mk'.
  Finished prerequisites of target file `/root/ltp-full-20091031/include/mk/config.mk'.
 No need to remake target `/root/ltp-full-20091031/include/mk/config.mk'.
 Considering target file `/root/ltp-full-20091031/include/mk/env_pre.mk'.
  Looking for an implicit rule for `/root/ltp-full-20091031/include/mk/env_pre.mk'.
  Trying pattern rule with stem `env_pre.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/env_pre.mk,v'.
  Trying pattern rule with stem `env_pre.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/RCS/env_pre.mk,v'.
  Trying pattern rule with stem `env_pre.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/RCS/env_pre.mk'.
  Trying pattern rule with stem `env_pre.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/s.env_pre.mk'.
  Trying pattern rule with stem `env_pre.mk'.
  Trying implicit prerequisite `/root/ltp-full-20091031/include/mk/SCCS/s.env_pre.mk'.
  No implicit rule found for `/root/ltp-full-20091031/include/mk/env_pre.mk'.
  Finished prerequisites of target file `/root/ltp-full-20091031/include/mk/env_pre.mk'.
 No need to remake target `/root/ltp-full-20091031/include/mk/env_pre.mk'.
 Considering target file `Makefile'.
  Looking for an implicit rule for `Makefile'.
  Trying pattern rule with stem `Makefile'.
  Trying implicit prerequisite `Makefile,v'.
  Trying pattern rule with stem `Makefile'.
  Trying implicit prerequisite `RCS/Makefile,v'.
  Trying pattern rule with stem `Makefile'.
  Trying implicit prerequisite `RCS/Makefile'.
  Trying pattern rule with stem `Makefile'.
  Trying implicit prerequisite `s.Makefile'.
  Trying pattern rule with stem `Makefile'.
  Trying implicit prerequisite `SCCS/s.Makefile'.
  No implicit rule found for `Makefile'.
  Finished prerequisites of target file `Makefile'.
 No need to remake target `Makefile'.
Updating goal targets....
Considering target file `testcases/realtime/configure'.
 Finished prerequisites of target file `testcases/realtime/configure'.
No need to remake target `testcases/realtime/configure'.
make: `testcases/realtime/configure' is up to date.



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 1595 bytes --]

On Friday 06 November 2009 08:09:06 Andi Kleen wrote:
> On Fri, Nov 06, 2009 at 07:16:39AM -0400, Mike Frysinger wrote:
> > On Friday 06 November 2009 04:57:45 Andi Kleen wrote:
> > > I ran configure, which seems to spend 99% of its time
> > > checking for stuff that is always there on any Linux,
> >
> > not really.  most of the configure checks are there because people have
> > complained about specific issues trying to run on older linux distros. 
> > and we
> 
> I always just deleted the tests that didn't build. That's far better
> than not building at all like now.

perhaps an acceptable workaround for you, but certainly not for most people

> > arent actively blocking using LTP on other *nix systems.
> 
> yes you're just actively blocking running LTP on Linux now it seems.

please refrain from filling e-mails with unrelated BS

> > > and after that I just get
> > >
> > > # make
> > > make: `testcases/realtime/configure' is up to date.
> > > #
> >
> > -ENEEDINFO
> >
> > are you using live cvs ?  latest release ?  what distro ?  what version
> > of
> 
> See Subject on SUSE 10.0
> 
> > autoconf/make ?  what does `make -d` show ?
> 
> autoconf doesn't matter because I didn't regenerate the script.
> 
> GNU Make 3.80

looks like a bug in make-3.80.  works fine with make-3.81.  care to take a 
look Garrett ?

usually i just install older versions on my system as `make-$VER` to make 
testing different ones easy.  since all the makefiles use $(MAKE), this 
shouldnt be a problem to execute `make-$VER` instead of `make`.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Fri, Nov 6, 2009 at 5:21 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday 06 November 2009 08:09:06 Andi Kleen wrote:
>> On Fri, Nov 06, 2009 at 07:16:39AM -0400, Mike Frysinger wrote:
>> > On Friday 06 November 2009 04:57:45 Andi Kleen wrote:
>> > > I ran configure, which seems to spend 99% of its time
>> > > checking for stuff that is always there on any Linux,
>> >
>> > not really.  most of the configure checks are there because people have
>> > complained about specific issues trying to run on older linux distros.
>> > and we
>>
>> I always just deleted the tests that didn't build. That's far better
>> than not building at all like now.
>
> perhaps an acceptable workaround for you, but certainly not for most people
>
>> > arent actively blocking using LTP on other *nix systems.
>>
>> yes you're just actively blocking running LTP on Linux now it seems.
>
> please refrain from filling e-mails with unrelated BS
>
>> > > and after that I just get
>> > >
>> > > # make
>> > > make: `testcases/realtime/configure' is up to date.
>> > > #
>> >
>> > -ENEEDINFO
>> >
>> > are you using live cvs ?  latest release ?  what distro ?  what version
>> > of
>>
>> See Subject on SUSE 10.0
>>
>> > autoconf/make ?  what does `make -d` show ?
>>
>> autoconf doesn't matter because I didn't regenerate the script.
>>
>> GNU Make 3.80
>
> looks like a bug in make-3.80.  works fine with make-3.81.  care to take a
> look Garrett ?
>
> usually i just install older versions on my system as `make-$VER` to make
> testing different ones easy.  since all the makefiles use $(MAKE), this
> shouldnt be a problem to execute `make-$VER` instead of `make`.

Hi Andi,

As I just wrote in the INSTALL file after the release (I apologize for
not catching this beforehand, but all of the systems I use -- Fedora,
Gentoo, RHEL 4 update 6, Ubuntu -- have make 3.81):

======================================================

In order to compile and use pan, you must have bison/yacc, flex, and make
3.81+ installed.

# ...

make 3.81 can be obtained here:
- http://ftp.gnu.org/gnu/make/make-3.81.tar.bz2

# ...

Common Issues
----------------------

Issue:    When executing make [all] it says:

    " *** No rule to make target `/$*', needed by `pan-all'.  Stop."

Solution: You must upgrade to make 3.81. Please see the Requirements
section above.

Issue:    When executing make [all] it says something like:

    # ...
    install -m 00644 "/scratch/ltp-dev2/ltp/include/test.h"
"/scratch/ltp-install12/include/test.h"
    install -m 00644 "/scratch/ltp-dev2/ltp/include/tlibio.h"
"/scratch/ltp-install12/include/tlibio.h"
    install -m 00644 "/scratch/ltp-dev2/ltp/include/usctest.h"
"/scratch/ltp-install12/include/usctest.h"
    install -m 00644 "/scratch/ltp-dev2/ltp/include/write_log.h"
"/scratch/ltp-install12/include/write_log.h"
    make[1]: Leaving directory `/scratch/ltp-dev2/ltp/include'
    make -C lib -f "/scratch/ltp-dev2/ltp/lib/Makefile" all
    make[1]: Entering directory `/scratch/ltp-dev2/ltp/lib'
    " *** No rule to make target `dataascii.o', needed by `libltp.a'.
Stop." # <-- the error

Solution: You cannot build LTP with -r / --no-builtin-rules and/or
          -R / --no-builtin-variables specified. LTP relies heavily on built-in
          implicit rules and variables to function properly.

======================================================

So yes, there are known issues with using make versions <3.81. The
reason being that some macros and functions that I use to determine
absolute path, etc were not available in make 3.80.

I've considered adding a configure check for the make version. I'm
probably going to do it this weekend to avoid support issues like
these.

Thanks,
-Garrett

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Fri, Nov 6, 2009 at 10:04 AM, Garrett Cooper <yanegomi@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 5:21 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Friday 06 November 2009 08:09:06 Andi Kleen wrote:
>>> On Fri, Nov 06, 2009 at 07:16:39AM -0400, Mike Frysinger wrote:
>>> > On Friday 06 November 2009 04:57:45 Andi Kleen wrote:
>>> > > I ran configure, which seems to spend 99% of its time
>>> > > checking for stuff that is always there on any Linux,
>>> >
>>> > not really.  most of the configure checks are there because people have
>>> > complained about specific issues trying to run on older linux distros.
>>> > and we
>>>
>>> I always just deleted the tests that didn't build. That's far better
>>> than not building at all like now.
>>
>> perhaps an acceptable workaround for you, but certainly not for most people
>>
>>> > arent actively blocking using LTP on other *nix systems.
>>>
>>> yes you're just actively blocking running LTP on Linux now it seems.
>>
>> please refrain from filling e-mails with unrelated BS
>>
>>> > > and after that I just get
>>> > >
>>> > > # make
>>> > > make: `testcases/realtime/configure' is up to date.
>>> > > #
>>> >
>>> > -ENEEDINFO
>>> >
>>> > are you using live cvs ?  latest release ?  what distro ?  what version
>>> > of
>>>
>>> See Subject on SUSE 10.0
>>>
>>> > autoconf/make ?  what does `make -d` show ?
>>>
>>> autoconf doesn't matter because I didn't regenerate the script.
>>>
>>> GNU Make 3.80
>>
>> looks like a bug in make-3.80.  works fine with make-3.81.  care to take a
>> look Garrett ?
>>
>> usually i just install older versions on my system as `make-$VER` to make
>> testing different ones easy.  since all the makefiles use $(MAKE), this
>> shouldnt be a problem to execute `make-$VER` instead of `make`.
>
> Hi Andi,
>
> As I just wrote in the INSTALL file after the release (I apologize for
> not catching this beforehand, but all of the systems I use -- Fedora,
> Gentoo, RHEL 4 update 6, Ubuntu -- have make 3.81):
>
> ======================================================
>
> In order to compile and use pan, you must have bison/yacc, flex, and make
> 3.81+ installed.

I reread this statement and it is ambiguous. I just changed it in CVS
to state the following:

1. In order to compile ltp you must have make 3.81+.
2. In order to compile and use pan, you must have bison/yacc, and flex
installed.

> # ...
>
> make 3.81 can be obtained here:
> - http://ftp.gnu.org/gnu/make/make-3.81.tar.bz2
>
> # ...
>
> Common Issues
> ----------------------
>
> Issue:    When executing make [all] it says:
>
>    " *** No rule to make target `/$*', needed by `pan-all'.  Stop."
>
> Solution: You must upgrade to make 3.81. Please see the Requirements
> section above.
>
> Issue:    When executing make [all] it says something like:
>
>    # ...
>    install -m 00644 "/scratch/ltp-dev2/ltp/include/test.h"
> "/scratch/ltp-install12/include/test.h"
>    install -m 00644 "/scratch/ltp-dev2/ltp/include/tlibio.h"
> "/scratch/ltp-install12/include/tlibio.h"
>    install -m 00644 "/scratch/ltp-dev2/ltp/include/usctest.h"
> "/scratch/ltp-install12/include/usctest.h"
>    install -m 00644 "/scratch/ltp-dev2/ltp/include/write_log.h"
> "/scratch/ltp-install12/include/write_log.h"
>    make[1]: Leaving directory `/scratch/ltp-dev2/ltp/include'
>    make -C lib -f "/scratch/ltp-dev2/ltp/lib/Makefile" all
>    make[1]: Entering directory `/scratch/ltp-dev2/ltp/lib'
>    " *** No rule to make target `dataascii.o', needed by `libltp.a'.
> Stop." # <-- the error
>
> Solution: You cannot build LTP with -r / --no-builtin-rules and/or
>          -R / --no-builtin-variables specified. LTP relies heavily on built-in
>          implicit rules and variables to function properly.
>
> ======================================================
>
> So yes, there are known issues with using make versions <3.81. The
> reason being that some macros and functions that I use to determine
> absolute path, etc were not available in make 3.80.
>
> I've considered adding a configure check for the make version. I'm
> probably going to do it this weekend to avoid support issues like
> these.
>
> Thanks,
> -Garrett
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 1025 bytes --]

On Friday 06 November 2009 13:04:51 Garrett Cooper wrote:
> As I just wrote in the INSTALL file after the release (I apologize for
> not catching this beforehand, but all of the systems I use -- Fedora,
> Gentoo, RHEL 4 update 6, Ubuntu -- have make 3.81):

hrm, it sucks to not support make 3.80.  while make 3.81 has been out for 
three years now, make 3.80 support would increase the coverage to 8 years.  
but if you've looked at the situation and found 3.80 support to be non 
trivial, i wont whine too loud.

> In order to compile and use pan, you must have bison/yacc, flex, and make
> 3.81+ installed.

if we're forcing make-3.81+, then make it explicit:
ifneq ($(findstring x3.7,x$(MAKE_VERSION)),)
NEED_NEWER_MAKE := y
endif
ifeq ($(MAKE_VERSION),3.80)
NEED_NEWER_MAKE := y
endif
ifeq ($(NEED_NEWER_MAKE),y)
$(error ..)
endif

also, i thought we were going to rename the top level Makefile to GNUmakefile 
and add a dummy Makefile that just spat out "sorry, ltp requires GNU make".
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
> On Friday 06 November 2009 13:04:51 Garrett Cooper wrote:
> > As I just wrote in the INSTALL file after the release (I apologize for
> > not catching this beforehand, but all of the systems I use -- Fedora,
> > Gentoo, RHEL 4 update 6, Ubuntu -- have make 3.81):
> 
> hrm, it sucks to not support make 3.80.  while make 3.81 has been out for 
> three years now, make 3.80 support would increase the coverage to 8 years.  
> but if you've looked at the situation and found 3.80 support to be non 
> trivial, i wont whine too loud.

Well I do whine. I essentially means that I won't be able to use
newer LTP versions anymore in my standard test setup. And I know
it's pretty common with kernel hackers to use old user lands:
you're basically cutting yourself off from your customer base.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Cyril Hrubis]

Hi!
> > > As I just wrote in the INSTALL file after the release (I apologize for
> > > not catching this beforehand, but all of the systems I use -- Fedora,
> > > Gentoo, RHEL 4 update 6, Ubuntu -- have make 3.81):
> > 
> > hrm, it sucks to not support make 3.80.  while make 3.81 has been out for 
> > three years now, make 3.80 support would increase the coverage to 8 years.  
> > but if you've looked at the situation and found 3.80 support to be non 
> > trivial, i wont whine too loud.
> 
> Well I do whine. I essentially means that I won't be able to use
> newer LTP versions anymore in my standard test setup. And I know
> it's pretty common with kernel hackers to use old user lands:
> you're basically cutting yourself off from your customer base.
>

Me too please, that would definitively broke package building process as it's
not that easy to hack the magick box called buildsystem to use different
version of packages (even if they build properly on given distro version).
Forcing user to use newer make is good workaround for some time but IMHO not
propper solution.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Matt Helsley]

On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
> On Friday 06 November 2009 13:04:51 Garrett Cooper wrote:
> > As I just wrote in the INSTALL file after the release (I apologize for
> > not catching this beforehand, but all of the systems I use -- Fedora,
> > Gentoo, RHEL 4 update 6, Ubuntu -- have make 3.81):
> 
> hrm, it sucks to not support make 3.80.  while make 3.81 has been out for 
> three years now, make 3.80 support would increase the coverage to 8 years.  
> but if you've looked at the situation and found 3.80 support to be non 
> trivial, i wont whine too loud.
> 
> > In order to compile and use pan, you must have bison/yacc, flex, and make
> > 3.81+ installed.
> 
> if we're forcing make-3.81+, then make it explicit:
> ifneq ($(findstring x3.7,x$(MAKE_VERSION)),)

This snippet might work better than findstring. If the make version is
greater than or equal to 3.81 then NEED_NEWER_MAKE is n:

NEED_NEWER_MAKE := n
MAX_VERSION := $(shell echo 3.81 $(MAKE_VERSION) | xargs -r -n 1 | sort -V -r | head -n 1)
ifneq(x$(MAKE_VERSION),x$(MAX_VERSION))
NEED_NEWER_MAKE := y
endif

(I tried to make this a into neat sortv Make "function" but couldn't
get arg passing to work :P)

> NEED_NEWER_MAKE := y
> endif
> ifeq ($(MAKE_VERSION),3.80)
> NEED_NEWER_MAKE := y
> endif
> ifeq ($(NEED_NEWER_MAKE),y)
> $(error ..)
> endif
> 
> also, i thought we were going to rename the top level Makefile to GNUmakefile 
> and add a dummy Makefile that just spat out "sorry, ltp requires GNU make".

Bleh. Can't we just check the output of $(MAKE) --version rather than
assume other makes use "Makefile"?

Cheers,
	-Matt Helsley

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 1748 bytes --]

On Friday 06 November 2009 18:02:31 Matt Helsley wrote:
> On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
> > On Friday 06 November 2009 13:04:51 Garrett Cooper wrote:
> > > As I just wrote in the INSTALL file after the release (I apologize for
> > > not catching this beforehand, but all of the systems I use -- Fedora,
> > > Gentoo, RHEL 4 update 6, Ubuntu -- have make 3.81):
> >
> > hrm, it sucks to not support make 3.80.  while make 3.81 has been out for
> > three years now, make 3.80 support would increase the coverage to 8
> > years. but if you've looked at the situation and found 3.80 support to be
> > non trivial, i wont whine too loud.
> >
> > > In order to compile and use pan, you must have bison/yacc, flex, and
> > > make 3.81+ installed.
> >
> > if we're forcing make-3.81+, then make it explicit:
> > ifneq ($(findstring x3.7,x$(MAKE_VERSION)),)
> 
> This snippet might work better than findstring. If the make version is
> greater than or equal to 3.81 then NEED_NEWER_MAKE is n:
> 
> NEED_NEWER_MAKE := n
> MAX_VERSION := $(shell echo 3.81 $(MAKE_VERSION) | xargs -r -n 1 | sort -V
>  -r | head -n 1)

this involves executing a shell and a lot of external utilities.  my version 
requires an internal make string search.  anything that involves $(shell) here 
is going to be worse.

> > also, i thought we were going to rename the top level Makefile to
> > GNUmakefile and add a dummy Makefile that just spat out "sorry, ltp
> > requires GNU make".
> 
> Bleh. Can't we just check the output of $(MAKE) --version rather than
> assume other makes use "Makefile"?

the assumption is that only GNU make parses "GNUmakefile".  i think that's a 
pretty safe assumption.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Matt Helsley]

On Fri, Nov 06, 2009 at 06:09:04PM -0500, Mike Frysinger wrote:
> On Friday 06 November 2009 18:02:31 Matt Helsley wrote:
> > On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
> > > On Friday 06 November 2009 13:04:51 Garrett Cooper wrote:

<snip>

> > This snippet might work better than findstring. If the make version is
> > greater than or equal to 3.81 then NEED_NEWER_MAKE is n:
> > 
> > NEED_NEWER_MAKE := n
> > MAX_VERSION := $(shell echo 3.81 $(MAKE_VERSION) | xargs -r -n 1 | sort -V
> >  -r | head -n 1)
> 
> this involves executing a shell and a lot of external utilities.  my version 
> requires an internal make string search.  anything that involves $(shell) here 
> is going to be worse.

OK -- I don't know whether old versions of xargs and sort take those
arguments and you seem to know those kinds of details better than I.

> > > also, i thought we were going to rename the top level Makefile to
> > > GNUmakefile and add a dummy Makefile that just spat out "sorry, ltp
> > > requires GNU make".
> > 
> > Bleh. Can't we just check the output of $(MAKE) --version rather than
> > assume other makes use "Makefile"?
> 
> the assumption is that only GNU make parses "GNUmakefile".  i think that's a 
> pretty safe assumption.

Right, but GNU Make also parses Makefile. If some poor bastard runs:

make -f Makefile

where GNU Make is "make" they may be further confused. Seems like it's
better to check what's actually running ($(MAKE)) or will run
(like `which make` in configure) than rely on a filename hack like this.

Cheers,
	-Matt Helsley

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 1993 bytes --]

On Friday 06 November 2009 18:34:22 Matt Helsley wrote:
> On Fri, Nov 06, 2009 at 06:09:04PM -0500, Mike Frysinger wrote:
> > On Friday 06 November 2009 18:02:31 Matt Helsley wrote:
> > > On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
> > > > also, i thought we were going to rename the top level Makefile to
> > > > GNUmakefile and add a dummy Makefile that just spat out "sorry, ltp
> > > > requires GNU make".
> > >
> > > Bleh. Can't we just check the output of $(MAKE) --version rather than
> > > assume other makes use "Makefile"?
> >
> > the assumption is that only GNU make parses "GNUmakefile".  i think
> > that's a pretty safe assumption.
> 
> Right, but GNU Make also parses Makefile.

not if a GNUmakefile exists in the same dir, or the user forces the issue via 
the -f flag

> If some poor bastard runs:
> 
> make -f Makefile
> 
> where GNU Make is "make" they may be further confused. Seems like it's
> better to check what's actually running ($(MAKE)) or will run
> (like `which make` in configure) than rely on a filename hack like this.

said poor bastard should be smacked :p.  checking the value of $(MAKE) wont 
work as it could be an arbitrary number of things which could all be valid 
values under GNU make.  configure checks wont matter because it's the user who 
runs `make` or `gmake` or `make-some-noise`.  requiring `make` to be GNU make 
in configure when the user can easily run `gmake` at make time is pointless 
user interference.

using a different filename on the other hand is exactly what GNU make has 
designed in from the get go specifically for this purpose -- when GNU make is 
required.  if you honestly think people are doing something pointless like 
`make -f Makefile`, then it's trivial to add a check to it to (1) check 
$(MAKE) --version and include GNUmakefile or (2) $(error out).  no point in 
forcing the shell/etc... overhead in the default build for the majority of 
users.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Fri, Nov 6, 2009 at 4:23 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday 06 November 2009 18:34:22 Matt Helsley wrote:
>> On Fri, Nov 06, 2009 at 06:09:04PM -0500, Mike Frysinger wrote:
>> > On Friday 06 November 2009 18:02:31 Matt Helsley wrote:
>> > > On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
>> > > > also, i thought we were going to rename the top level Makefile to
>> > > > GNUmakefile and add a dummy Makefile that just spat out "sorry, ltp
>> > > > requires GNU make".
>> > >
>> > > Bleh. Can't we just check the output of $(MAKE) --version rather than
>> > > assume other makes use "Makefile"?
>> >
>> > the assumption is that only GNU make parses "GNUmakefile".  i think
>> > that's a pretty safe assumption.
>>
>> Right, but GNU Make also parses Makefile.
>
> not if a GNUmakefile exists in the same dir, or the user forces the issue via
> the -f flag
>
>> If some poor bastard runs:
>>
>> make -f Makefile
>>
>> where GNU Make is "make" they may be further confused. Seems like it's
>> better to check what's actually running ($(MAKE)) or will run
>> (like `which make` in configure) than rely on a filename hack like this.
>
> said poor bastard should be smacked :p.  checking the value of $(MAKE) wont
> work as it could be an arbitrary number of things which could all be valid
> values under GNU make.  configure checks wont matter because it's the user who
> runs `make` or `gmake` or `make-some-noise`.  requiring `make` to be GNU make
> in configure when the user can easily run `gmake` at make time is pointless
> user interference.
>
> using a different filename on the other hand is exactly what GNU make has
> designed in from the get go specifically for this purpose -- when GNU make is
> required.  if you honestly think people are doing something pointless like
> `make -f Makefile`, then it's trivial to add a check to it to (1) check
> $(MAKE) --version and include GNUmakefile or (2) $(error out).  no point in
> forcing the shell/etc... overhead in the default build for the majority of
> users.

No, but you can do something like:

ifdef MAKE_SANITY_CHECK
export MAKE_SANITY_CHECK = 1
ifneq ($(lastword $(sort 3.80 $(MAKE_VERSION))),$(MAKE_VERSION))
$(error Upgrade your junk..)
endif
endif

that way it only executes this once.

-Garrett

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Fri, Nov 6, 2009 at 4:52 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 4:23 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Friday 06 November 2009 18:34:22 Matt Helsley wrote:
>>> On Fri, Nov 06, 2009 at 06:09:04PM -0500, Mike Frysinger wrote:
>>> > On Friday 06 November 2009 18:02:31 Matt Helsley wrote:
>>> > > On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
>>> > > > also, i thought we were going to rename the top level Makefile to
>>> > > > GNUmakefile and add a dummy Makefile that just spat out "sorry, ltp
>>> > > > requires GNU make".
>>> > >
>>> > > Bleh. Can't we just check the output of $(MAKE) --version rather than
>>> > > assume other makes use "Makefile"?
>>> >
>>> > the assumption is that only GNU make parses "GNUmakefile".  i think
>>> > that's a pretty safe assumption.
>>>
>>> Right, but GNU Make also parses Makefile.
>>
>> not if a GNUmakefile exists in the same dir, or the user forces the issue via
>> the -f flag
>>
>>> If some poor bastard runs:
>>>
>>> make -f Makefile
>>>
>>> where GNU Make is "make" they may be further confused. Seems like it's
>>> better to check what's actually running ($(MAKE)) or will run
>>> (like `which make` in configure) than rely on a filename hack like this.
>>
>> said poor bastard should be smacked :p.  checking the value of $(MAKE) wont
>> work as it could be an arbitrary number of things which could all be valid
>> values under GNU make.  configure checks wont matter because it's the user who
>> runs `make` or `gmake` or `make-some-noise`.  requiring `make` to be GNU make
>> in configure when the user can easily run `gmake` at make time is pointless
>> user interference.
>>
>> using a different filename on the other hand is exactly what GNU make has
>> designed in from the get go specifically for this purpose -- when GNU make is
>> required.  if you honestly think people are doing something pointless like
>> `make -f Makefile`, then it's trivial to add a check to it to (1) check
>> $(MAKE) --version and include GNUmakefile or (2) $(error out).  no point in
>> forcing the shell/etc... overhead in the default build for the majority of
>> users.
>
> No, but you can do something like:
>
> ifdef MAKE_SANITY_CHECK
> export MAKE_SANITY_CHECK = 1
> ifneq ($(lastword $(sort 3.80 $(MAKE_VERSION))),$(MAKE_VERSION))
> $(error Upgrade your junk..)
> endif
> endif
>
> that way it only executes this once.

Ugh... $(lastword ) didn't exist in 3.80... I'll change it around to
$(firstword ).

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Fri, Nov 6, 2009 at 4:54 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 4:52 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
>> On Fri, Nov 6, 2009 at 4:23 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>>> On Friday 06 November 2009 18:34:22 Matt Helsley wrote:
>>>> On Fri, Nov 06, 2009 at 06:09:04PM -0500, Mike Frysinger wrote:
>>>> > On Friday 06 November 2009 18:02:31 Matt Helsley wrote:
>>>> > > On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
>>>> > > > also, i thought we were going to rename the top level Makefile to
>>>> > > > GNUmakefile and add a dummy Makefile that just spat out "sorry, ltp
>>>> > > > requires GNU make".
>>>> > >
>>>> > > Bleh. Can't we just check the output of $(MAKE) --version rather than
>>>> > > assume other makes use "Makefile"?
>>>> >
>>>> > the assumption is that only GNU make parses "GNUmakefile".  i think
>>>> > that's a pretty safe assumption.
>>>>
>>>> Right, but GNU Make also parses Makefile.
>>>
>>> not if a GNUmakefile exists in the same dir, or the user forces the issue via
>>> the -f flag
>>>
>>>> If some poor bastard runs:
>>>>
>>>> make -f Makefile
>>>>
>>>> where GNU Make is "make" they may be further confused. Seems like it's
>>>> better to check what's actually running ($(MAKE)) or will run
>>>> (like `which make` in configure) than rely on a filename hack like this.
>>>
>>> said poor bastard should be smacked :p.  checking the value of $(MAKE) wont
>>> work as it could be an arbitrary number of things which could all be valid
>>> values under GNU make.  configure checks wont matter because it's the user who
>>> runs `make` or `gmake` or `make-some-noise`.  requiring `make` to be GNU make
>>> in configure when the user can easily run `gmake` at make time is pointless
>>> user interference.
>>>
>>> using a different filename on the other hand is exactly what GNU make has
>>> designed in from the get go specifically for this purpose -- when GNU make is
>>> required.  if you honestly think people are doing something pointless like
>>> `make -f Makefile`, then it's trivial to add a check to it to (1) check
>>> $(MAKE) --version and include GNUmakefile or (2) $(error out).  no point in
>>> forcing the shell/etc... overhead in the default build for the majority of
>>> users.
>>
>> No, but you can do something like:
>>
>> ifdef MAKE_SANITY_CHECK
>> export MAKE_SANITY_CHECK = 1
>> ifneq ($(lastword $(sort 3.80 $(MAKE_VERSION))),$(MAKE_VERSION))
>> $(error Upgrade your junk..)
>> endif
>> endif
>>
>> that way it only executes this once.
>
> Ugh... $(lastword ) didn't exist in 3.80... I'll change it around to
> $(firstword ).

Crap. So here are some of the high notes for changes between make 3.80 and 3.81:

1. $(and ) and $(or ) didn't exist [we use $(or ) once]. This can be
replaced by an `ifeq ($(strip)) else endif'.
2. $(abspath ) // $(realpath ) didn't exist [we use $(abspath )
extensively, but just in one spot -- fixed that, need to test].
3. .DEFAULT_GOAL was originally .DEFAULT_TARGET, but DID NOT exist in
make 3.81 (this is going to be a bloody pain to hack around with,
maybe -- depends on where I put all:). It'll be like herding cats to
make sure that other developers don't create targets before the first
include.
4. Secondary expansion was busted as all hell in <3.81 (now this is
going to be a serious pain point in some areas because I'll have to
hunt down wherever I used % and $* and adjust things to work with make
3.80 -- this mostly affects the top-level Makefile).
5. Secondary expansion did NOT exist in static nor implicit rules
(another pain point -- mostly with the top-level Makefile).
6. $(lastword ) didn't exist [can be replaced by $(firstword ) with
inverse logic, maybe...].
7. Some funkiness with how .PHONY was treated:

2004-09-21  Boris Kolpackov  <boris@kolpackov.net>

        * file.c (snap_deps): Mark .PHONY prerequisites as targets.

8. Variable expansion was partially broken [used underlying caller
from $(subst ) instead of $(patsubst )].
9. Now this one flat out spooks me:

2004-03-20  Paul D. Smith  <psmith@gnu.org>

[...]

        * rule.c (count_implicit_rule_limits): Don't delete patterns which
        refer to absolute pathnames in directories that don't exist: some
        portion of the makefile could create those directories before we
        match the pattern.  Fixes bugs #775 and #108.

  This makes me think that out-of-build-tree could be REALLY broken with 3.80.

10. Ouch -- this is a really f'ed up bug:

2004-01-07  Paul D. Smith  <psmith@gnu.org>

[...]

        * job.c (construct_command_argv_internal): Add "!" to the list of
        shell escape chars.  POSIX sh allows it to appear before a
        command, to negate the exit code.  Fixes bug #6404.

11. Yipes -- this scares me because we do use implicit and pattern rules:

2003-04-19  Paul D. Smith  <psmith@gnu.org>

        Fix bug #1405: allow a target to match multiple pattern-specific
        variables.

        * rule.c (create_pattern_var, lookup_pattern_var): Move these to
        variable.c, where they've always belonged.
        * rule.h: Move the prototypes and struct pattern_var as well.
        * variable.c (initialize_file_variables): Invoke
        lookup_pattern_var() in a loop, until no more matches are found.
        If a match is found, create a new variable set for the target's
        pattern variables.  Then merge the contents of each matching
        pattern variable set into the target's pattern variable set.
        (lookup_pattern_var): Change this function to be usable
        in a loop.  It takes a starting position: if NULL, start at the
        beginning; if non-NULL, start with the pattern variable after that
        position, and return the next matching pattern.
        (create_pattern_var): Create a unique instance of
        pattern-specific variables for every definition in the makefile.
        Don't combine the same pattern together.  This allows us to
        process the variable handling properly even when the same pattern
        is used multiple times.
        (parse_variable_definition): New function: break out the parsing
        of a variable definition line from try_variable_definition.
        (try_variable_definition): Call parse_variable_definition to
        parse.
        (print_variable_data_base): Print out pattern-specific variables.
        * variable.h (struct variable): Remember when a variable is
        conditional.  Also remember its flavor.
        (struct pattern_var): Instead of keeping a variable set, we just
        keep a single variable for each pattern.
        * read.c (record_target_var): Each pattern variable contains only a
        single variable, not a set, so create it properly.
        * doc/make.texi (Pattern-specific): Document the new behavior

12. Hmmm -- this could get nasty:

2003-01-22  Paul D. Smith  <psmith@gnu.org>

        * function.c (func_call): Fix Bug #1744.  If we're inside a
        recursive invocation of $(call ...), mask any of the outer
        invocation's arguments that aren't used by this one, so that this
        invocation doesn't "inherit" them accidentally.

I'm concerned now that this is going to take 4 +/- 1 weekends to
complete and will be semi-painful to validate... The funny thing is
that our Makefiles were implementing some of this logic before (in a
hodgepodge manner), so this maybe some items like these were failing
in the past but not being caught, or were masked by all of the
explicit target specifications which are a MFPiTA to maintain.

Thoughts :\?

Thanks,
-Garrett

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Sat, Nov 7, 2009 at 6:09 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 4:54 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
>> On Fri, Nov 6, 2009 at 4:52 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
>>> On Fri, Nov 6, 2009 at 4:23 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>>>> On Friday 06 November 2009 18:34:22 Matt Helsley wrote:
>>>>> On Fri, Nov 06, 2009 at 06:09:04PM -0500, Mike Frysinger wrote:
>>>>> > On Friday 06 November 2009 18:02:31 Matt Helsley wrote:
>>>>> > > On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
>>>>> > > > also, i thought we were going to rename the top level Makefile to
>>>>> > > > GNUmakefile and add a dummy Makefile that just spat out "sorry, ltp
>>>>> > > > requires GNU make".
>>>>> > >
>>>>> > > Bleh. Can't we just check the output of $(MAKE) --version rather than
>>>>> > > assume other makes use "Makefile"?
>>>>> >
>>>>> > the assumption is that only GNU make parses "GNUmakefile".  i think
>>>>> > that's a pretty safe assumption.
>>>>>
>>>>> Right, but GNU Make also parses Makefile.
>>>>
>>>> not if a GNUmakefile exists in the same dir, or the user forces the issue via
>>>> the -f flag
>>>>
>>>>> If some poor bastard runs:
>>>>>
>>>>> make -f Makefile
>>>>>
>>>>> where GNU Make is "make" they may be further confused. Seems like it's
>>>>> better to check what's actually running ($(MAKE)) or will run
>>>>> (like `which make` in configure) than rely on a filename hack like this.
>>>>
>>>> said poor bastard should be smacked :p.  checking the value of $(MAKE) wont
>>>> work as it could be an arbitrary number of things which could all be valid
>>>> values under GNU make.  configure checks wont matter because it's the user who
>>>> runs `make` or `gmake` or `make-some-noise`.  requiring `make` to be GNU make
>>>> in configure when the user can easily run `gmake` at make time is pointless
>>>> user interference.
>>>>
>>>> using a different filename on the other hand is exactly what GNU make has
>>>> designed in from the get go specifically for this purpose -- when GNU make is
>>>> required.  if you honestly think people are doing something pointless like
>>>> `make -f Makefile`, then it's trivial to add a check to it to (1) check
>>>> $(MAKE) --version and include GNUmakefile or (2) $(error out).  no point in
>>>> forcing the shell/etc... overhead in the default build for the majority of
>>>> users.
>>>
>>> No, but you can do something like:
>>>
>>> ifdef MAKE_SANITY_CHECK
>>> export MAKE_SANITY_CHECK = 1
>>> ifneq ($(lastword $(sort 3.80 $(MAKE_VERSION))),$(MAKE_VERSION))
>>> $(error Upgrade your junk..)
>>> endif
>>> endif
>>>
>>> that way it only executes this once.
>>
>> Ugh... $(lastword ) didn't exist in 3.80... I'll change it around to
>> $(firstword ).
>
> Crap. So here are some of the high notes for changes between make 3.80 and 3.81:
>
> 1. $(and ) and $(or ) didn't exist [we use $(or ) once]. This can be
> replaced by an `ifeq ($(strip)) else endif'.
> 2. $(abspath ) // $(realpath ) didn't exist [we use $(abspath )
> extensively, but just in one spot -- fixed that, need to test].
> 3. .DEFAULT_GOAL was originally .DEFAULT_TARGET, but DID NOT exist in
> make 3.81 (this is going to be a bloody pain to hack around with,
> maybe -- depends on where I put all:). It'll be like herding cats to
> make sure that other developers don't create targets before the first
> include.
> 4. Secondary expansion was busted as all hell in <3.81 (now this is
> going to be a serious pain point in some areas because I'll have to
> hunt down wherever I used % and $* and adjust things to work with make
> 3.80 -- this mostly affects the top-level Makefile).
> 5. Secondary expansion did NOT exist in static nor implicit rules
> (another pain point -- mostly with the top-level Makefile).
> 6. $(lastword ) didn't exist [can be replaced by $(firstword ) with
> inverse logic, maybe...].
> 7. Some funkiness with how .PHONY was treated:
>
> 2004-09-21  Boris Kolpackov  <boris@kolpackov.net>
>
>        * file.c (snap_deps): Mark .PHONY prerequisites as targets.
>
> 8. Variable expansion was partially broken [used underlying caller
> from $(subst ) instead of $(patsubst )].
> 9. Now this one flat out spooks me:
>
> 2004-03-20  Paul D. Smith  <psmith@gnu.org>
>
> [...]
>
>        * rule.c (count_implicit_rule_limits): Don't delete patterns which
>        refer to absolute pathnames in directories that don't exist: some
>        portion of the makefile could create those directories before we
>        match the pattern.  Fixes bugs #775 and #108.
>
>  This makes me think that out-of-build-tree could be REALLY broken with 3.80.
>
> 10. Ouch -- this is a really f'ed up bug:
>
> 2004-01-07  Paul D. Smith  <psmith@gnu.org>
>
> [...]
>
>        * job.c (construct_command_argv_internal): Add "!" to the list of
>        shell escape chars.  POSIX sh allows it to appear before a
>        command, to negate the exit code.  Fixes bug #6404.
>
> 11. Yipes -- this scares me because we do use implicit and pattern rules:
>
> 2003-04-19  Paul D. Smith  <psmith@gnu.org>
>
>        Fix bug #1405: allow a target to match multiple pattern-specific
>        variables.
>
>        * rule.c (create_pattern_var, lookup_pattern_var): Move these to
>        variable.c, where they've always belonged.
>        * rule.h: Move the prototypes and struct pattern_var as well.
>        * variable.c (initialize_file_variables): Invoke
>        lookup_pattern_var() in a loop, until no more matches are found.
>        If a match is found, create a new variable set for the target's
>        pattern variables.  Then merge the contents of each matching
>        pattern variable set into the target's pattern variable set.
>        (lookup_pattern_var): Change this function to be usable
>        in a loop.  It takes a starting position: if NULL, start at the
>        beginning; if non-NULL, start with the pattern variable after that
>        position, and return the next matching pattern.
>        (create_pattern_var): Create a unique instance of
>        pattern-specific variables for every definition in the makefile.
>        Don't combine the same pattern together.  This allows us to
>        process the variable handling properly even when the same pattern
>        is used multiple times.
>        (parse_variable_definition): New function: break out the parsing
>        of a variable definition line from try_variable_definition.
>        (try_variable_definition): Call parse_variable_definition to
>        parse.
>        (print_variable_data_base): Print out pattern-specific variables.
>        * variable.h (struct variable): Remember when a variable is
>        conditional.  Also remember its flavor.
>        (struct pattern_var): Instead of keeping a variable set, we just
>        keep a single variable for each pattern.
>        * read.c (record_target_var): Each pattern variable contains only a
>        single variable, not a set, so create it properly.
>        * doc/make.texi (Pattern-specific): Document the new behavior
>
> 12. Hmmm -- this could get nasty:
>
> 2003-01-22  Paul D. Smith  <psmith@gnu.org>
>
>        * function.c (func_call): Fix Bug #1744.  If we're inside a
>        recursive invocation of $(call ...), mask any of the outer
>        invocation's arguments that aren't used by this one, so that this
>        invocation doesn't "inherit" them accidentally.
>
> I'm concerned now that this is going to take 4 +/- 1 weekends to
> complete and will be semi-painful to validate... The funny thing is
> that our Makefiles were implementing some of this logic before (in a
> hodgepodge manner), so this maybe some items like these were failing
> in the past but not being caught, or were masked by all of the
> explicit target specifications which are a MFPiTA to maintain.

    I think what I need to do is run some tests in these problem areas
to figure out the gaps, now that I have an inkling of what might be
missing, so I can properly fill in the gaps if I can...
Thanks,
-Garrett

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Sun, Nov 8, 2009 at 12:02 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
> On Sat, Nov 7, 2009 at 6:09 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
>> On Fri, Nov 6, 2009 at 4:54 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
>>> On Fri, Nov 6, 2009 at 4:52 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
>>>> On Fri, Nov 6, 2009 at 4:23 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>>>>> On Friday 06 November 2009 18:34:22 Matt Helsley wrote:
>>>>>> On Fri, Nov 06, 2009 at 06:09:04PM -0500, Mike Frysinger wrote:
>>>>>> > On Friday 06 November 2009 18:02:31 Matt Helsley wrote:
>>>>>> > > On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote:
>>>>>> > > > also, i thought we were going to rename the top level Makefile to
>>>>>> > > > GNUmakefile and add a dummy Makefile that just spat out "sorry, ltp
>>>>>> > > > requires GNU make".
>>>>>> > >
>>>>>> > > Bleh. Can't we just check the output of $(MAKE) --version rather than
>>>>>> > > assume other makes use "Makefile"?
>>>>>> >
>>>>>> > the assumption is that only GNU make parses "GNUmakefile".  i think
>>>>>> > that's a pretty safe assumption.
>>>>>>
>>>>>> Right, but GNU Make also parses Makefile.
>>>>>
>>>>> not if a GNUmakefile exists in the same dir, or the user forces the issue via
>>>>> the -f flag
>>>>>
>>>>>> If some poor bastard runs:
>>>>>>
>>>>>> make -f Makefile
>>>>>>
>>>>>> where GNU Make is "make" they may be further confused. Seems like it's
>>>>>> better to check what's actually running ($(MAKE)) or will run
>>>>>> (like `which make` in configure) than rely on a filename hack like this.
>>>>>
>>>>> said poor bastard should be smacked :p.  checking the value of $(MAKE) wont
>>>>> work as it could be an arbitrary number of things which could all be valid
>>>>> values under GNU make.  configure checks wont matter because it's the user who
>>>>> runs `make` or `gmake` or `make-some-noise`.  requiring `make` to be GNU make
>>>>> in configure when the user can easily run `gmake` at make time is pointless
>>>>> user interference.
>>>>>
>>>>> using a different filename on the other hand is exactly what GNU make has
>>>>> designed in from the get go specifically for this purpose -- when GNU make is
>>>>> required.  if you honestly think people are doing something pointless like
>>>>> `make -f Makefile`, then it's trivial to add a check to it to (1) check
>>>>> $(MAKE) --version and include GNUmakefile or (2) $(error out).  no point in
>>>>> forcing the shell/etc... overhead in the default build for the majority of
>>>>> users.
>>>>
>>>> No, but you can do something like:
>>>>
>>>> ifdef MAKE_SANITY_CHECK
>>>> export MAKE_SANITY_CHECK = 1
>>>> ifneq ($(lastword $(sort 3.80 $(MAKE_VERSION))),$(MAKE_VERSION))
>>>> $(error Upgrade your junk..)
>>>> endif
>>>> endif
>>>>
>>>> that way it only executes this once.
>>>
>>> Ugh... $(lastword ) didn't exist in 3.80... I'll change it around to
>>> $(firstword ).
>>
>> Crap. So here are some of the high notes for changes between make 3.80 and 3.81:
>>
>> 1. $(and ) and $(or ) didn't exist [we use $(or ) once]. This can be
>> replaced by an `ifeq ($(strip)) else endif'.

Fixed~ish. This one's a minor pain with $(or ). $(if ) doesn't
function either because it appears to have been introduced in the same
timeframe -_-...

>> 2. $(abspath ) // $(realpath ) didn't exist [we use $(abspath )
>> extensively, but just in one spot -- fixed that, need to test].

Fixed.

>> 3. .DEFAULT_GOAL was originally .DEFAULT_TARGET, but DID NOT exist in
>> make 3.81 (this is going to be a bloody pain to hack around with,
>> maybe -- depends on where I put all:). It'll be like herding cats to
>> make sure that other developers don't create targets before the first
>> include.

Need to check.

>> 4. Secondary expansion was busted as all hell in <3.81 (now this is
>> going to be a serious pain point in some areas because I'll have to
>> hunt down wherever I used % and $* and adjust things to work with make
>> 3.80 -- this mostly affects the top-level Makefile).
>> 5. Secondary expansion did NOT exist in static nor implicit rules
>> (another pain point -- mostly with the top-level Makefile).

.SECONDEXPANSION - fixed.

>> 6. $(lastword ) didn't exist [can be replaced by $(firstword ) with
>> inverse logic, maybe...].
>> 7. Some funkiness with how .PHONY was treated:
>>
>> 2004-09-21  Boris Kolpackov  <boris@kolpackov.net>
>>
>>        * file.c (snap_deps): Mark .PHONY prerequisites as targets.
>>
>> 8. Variable expansion was partially broken [used underlying caller
>> from $(subst ) instead of $(patsubst )].
>> 9. Now this one flat out spooks me:
>>
>> 2004-03-20  Paul D. Smith  <psmith@gnu.org>
>>
>> [...]
>>
>>        * rule.c (count_implicit_rule_limits): Don't delete patterns which
>>        refer to absolute pathnames in directories that don't exist: some
>>        portion of the makefile could create those directories before we
>>        match the pattern.  Fixes bugs #775 and #108.
>>
>>  This makes me think that out-of-build-tree could be REALLY broken with 3.80.
>>
>> 10. Ouch -- this is a really f'ed up bug:
>>
>> 2004-01-07  Paul D. Smith  <psmith@gnu.org>
>>
>> [...]
>>
>>        * job.c (construct_command_argv_internal): Add "!" to the list of
>>        shell escape chars.  POSIX sh allows it to appear before a
>>        command, to negate the exit code.  Fixes bug #6404.
>>
>> 11. Yipes -- this scares me because we do use implicit and pattern rules:
>>
>> 2003-04-19  Paul D. Smith  <psmith@gnu.org>
>>
>>        Fix bug #1405: allow a target to match multiple pattern-specific
>>        variables.
>>
>>        * rule.c (create_pattern_var, lookup_pattern_var): Move these to
>>        variable.c, where they've always belonged.
>>        * rule.h: Move the prototypes and struct pattern_var as well.
>>        * variable.c (initialize_file_variables): Invoke
>>        lookup_pattern_var() in a loop, until no more matches are found.
>>        If a match is found, create a new variable set for the target's
>>        pattern variables.  Then merge the contents of each matching
>>        pattern variable set into the target's pattern variable set.
>>        (lookup_pattern_var): Change this function to be usable
>>        in a loop.  It takes a starting position: if NULL, start at the
>>        beginning; if non-NULL, start with the pattern variable after that
>>        position, and return the next matching pattern.
>>        (create_pattern_var): Create a unique instance of
>>        pattern-specific variables for every definition in the makefile.
>>        Don't combine the same pattern together.  This allows us to
>>        process the variable handling properly even when the same pattern
>>        is used multiple times.
>>        (parse_variable_definition): New function: break out the parsing
>>        of a variable definition line from try_variable_definition.
>>        (try_variable_definition): Call parse_variable_definition to
>>        parse.
>>        (print_variable_data_base): Print out pattern-specific variables.
>>        * variable.h (struct variable): Remember when a variable is
>>        conditional.  Also remember its flavor.
>>        (struct pattern_var): Instead of keeping a variable set, we just
>>        keep a single variable for each pattern.
>>        * read.c (record_target_var): Each pattern variable contains only a
>>        single variable, not a set, so create it properly.
>>        * doc/make.texi (Pattern-specific): Document the new behavior
>>
>> 12. Hmmm -- this could get nasty:
>>
>> 2003-01-22  Paul D. Smith  <psmith@gnu.org>
>>
>>        * function.c (func_call): Fix Bug #1744.  If we're inside a
>>        recursive invocation of $(call ...), mask any of the outer
>>        invocation's arguments that aren't used by this one, so that this
>>        invocation doesn't "inherit" them accidentally.
>>
>> I'm concerned now that this is going to take 4 +/- 1 weekends to
>> complete and will be semi-painful to validate... The funny thing is
>> that our Makefiles were implementing some of this logic before (in a
>> hodgepodge manner), so this maybe some items like these were failing
>> in the past but not being caught, or were masked by all of the
>> explicit target specifications which are a MFPiTA to maintain.
>
>    I think what I need to do is run some tests in these problem areas
> to figure out the gaps, now that I have an inkling of what might be
> missing, so I can properly fill in the gaps if I can...

Thanks,
-Garrett

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

> So yes, there are known issues with using make versions <3.81. The

For me it seems more the known issue is in the Makefile. 3.80
is a widely used Make version.

> reason being that some macros and functions that I use to determine
> absolute path, etc were not available in make 3.80.

Most of my infrastructure in test systems is based on SUSE 10.0 
and it's impractical to upgrade make everywhere.

I find it very sad that LTP now descended into "version hell"
and abandoned old distributions.
 
> I've considered adding a configure check for the make version. I'm
> probably going to do it this weekend to avoid support issues like
> these.

That's not a solution.

Please just fix the makefiles or revert this misguided change
and give us working makefiles back.

From a quick look at the mailing list archives that doesn't
even seem to be the only problem with this "improvement".

Thanks.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 826 bytes --]

On Friday 06 November 2009 14:13:43 Andi Kleen wrote:
> > I've considered adding a configure check for the make version. I'm
> > probably going to do it this weekend to avoid support issues like
> > these.
> 
> That's not a solution.
> 
> Please just fix the makefiles or revert this misguided change
> and give us working makefiles back.
> 
> From a quick look at the mailing list archives that doesn't
> even seem to be the only problem with this "improvement".

again, please stop wasting our time with your "revert it" comments.  it isnt 
going to happen.  especially considering you apparently have no signficant 
plans in helping maintain the huge code base that is LTP.

we can look at working around bugs in make-3.80 if/since there are a number of 
people who would like this functionality.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Fri, Nov 6, 2009 at 11:39 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday 06 November 2009 14:13:43 Andi Kleen wrote:
>> > I've considered adding a configure check for the make version. I'm
>> > probably going to do it this weekend to avoid support issues like
>> > these.
>>
>> That's not a solution.
>>
>> Please just fix the makefiles or revert this misguided change
>> and give us working makefiles back.
>>
>> From a quick look at the mailing list archives that doesn't
>> even seem to be the only problem with this "improvement".
>
> again, please stop wasting our time with your "revert it" comments.  it isnt
> going to happen.  especially considering you apparently have no signficant
> plans in helping maintain the huge code base that is LTP.
>
> we can look at working around bugs in make-3.80 if/since there are a number of
> people who would like this functionality.



I'll see whether or not there are other ways to skin the proverbial
can to get make 3.80 to work, but the problem is that what I'm going
to be providing in make <3.81 will be hacks, not solutions to fill in
functional gaps.

Also, mass deploying (IMO) make 3.81 shouldn't be that hard if the IT
infrastructure is setup properly with NFS or some other mass-package
deployment system. It's simply:

./configure [config-options]
make all install

Thanks,
-Garrett

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 1466 bytes --]

On Friday 06 November 2009 14:44:11 Garrett Cooper wrote:
> On Fri, Nov 6, 2009 at 11:39 AM, Mike Frysinger wrote:
> > On Friday 06 November 2009 14:13:43 Andi Kleen wrote:
> >> > I've considered adding a configure check for the make version. I'm
> >> > probably going to do it this weekend to avoid support issues like
> >> > these.
> >>
> >> That's not a solution.
> >>
> >> Please just fix the makefiles or revert this misguided change
> >> and give us working makefiles back.
> >>
> >> From a quick look at the mailing list archives that doesn't
> >> even seem to be the only problem with this "improvement".
> >
> > again, please stop wasting our time with your "revert it" comments.  it
> > isnt going to happen.  especially considering you apparently have no
> > signficant plans in helping maintain the huge code base that is LTP.
> >
> > we can look at working around bugs in make-3.80 if/since there are a
> > number of people who would like this functionality.
> 
> I'll see whether or not there are other ways to skin the proverbial
> can to get make 3.80 to work, but the problem is that what I'm going
> to be providing in make <3.81 will be hacks, not solutions to fill in
> functional gaps.

let's at least start out with the known bugs/limitations and see how/if each 
can be addressed.

sticking things behind something like this should be fine too:
ifeq ($(MAKE_VERSION),3.80)
# screw you make!
...
endif
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

On Fri, Nov 06, 2009 at 03:39:21PM -0400, Mike Frysinger wrote:
> On Friday 06 November 2009 14:13:43 Andi Kleen wrote:
> > > I've considered adding a configure check for the make version. I'm
> > > probably going to do it this weekend to avoid support issues like
> > > these.
> > 
> > That's not a solution.
> > 
> > Please just fix the makefiles or revert this misguided change
> > and give us working makefiles back.
> > 
> > From a quick look at the mailing list archives that doesn't
> > even seem to be the only problem with this "improvement".
> 
> again, please stop wasting our time with your "revert it" comments.  it isnt 

That's the standard strategy to fix regressions if the submitter
is unwilling to fix newly introduced bugs.

> going to happen.  especially considering you apparently have no signficant 
> plans in helping maintain the huge code base that is LTP.

I submitted some tests and fixes in the past, but yes I'm primarily a user.

> we can look at working around bugs in make-3.80 if/since there are a number of 
> people who would like this functionality.

Are you saying that LTP as a project is not interested in fixing regressions?

-Andi

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 1482 bytes --]

On Friday 06 November 2009 14:50:36 Andi Kleen wrote:
> On Fri, Nov 06, 2009 at 03:39:21PM -0400, Mike Frysinger wrote:
> > On Friday 06 November 2009 14:13:43 Andi Kleen wrote:
> > > > I've considered adding a configure check for the make version. I'm
> > > > probably going to do it this weekend to avoid support issues like
> > > > these.
> > >
> > > That's not a solution.
> > >
> > > Please just fix the makefiles or revert this misguided change
> > > and give us working makefiles back.
> > >
> > > From a quick look at the mailing list archives that doesn't
> > > even seem to be the only problem with this "improvement".
> >
> > again, please stop wasting our time with your "revert it" comments.  it
> > isnt
> 
> That's the standard strategy to fix regressions if the submitter
> is unwilling to fix newly introduced bugs.

your position on how to "fix" things is irrelevant here, nor is it helping in 
any way.  drop it.

> > we can look at working around bugs in make-3.80 if/since there are a
> > number of people who would like this functionality.
> 
> Are you saying that LTP as a project is not interested in fixing
>  regressions?

ive already made my position pretty clear in this statement.  support for old 
versions of tools will continually be phased out over time.  the exact cut off 
time will largely be dictated by the needs of the larger user base.  
"cleverly" defining behavior as "regressions" notwithstanding.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 633 bytes --]

On Friday 06 November 2009 14:50:36 Andi Kleen wrote:
> On Fri, Nov 06, 2009 at 03:39:21PM -0400, Mike Frysinger wrote:
> > going to happen.  especially considering you apparently have no
> > signficant plans in helping maintain the huge code base that is LTP.
> 
> I submitted some tests and fixes in the past, but yes I'm primarily a user.

right -- you've certainly contributed useful pieces in the past which is why i 
used the word "significant", but tackling the entire code base like Garrett 
has isnt a semi-trivial task, as well as fielding follow up reports.  i 
imagine it's been pretty draining on him.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Nate Straz]

On Nov  6 20:13, Andi Kleen wrote:
> > So yes, there are known issues with using make versions <3.81. The
> 
> For me it seems more the known issue is in the Makefile. 3.80
> is a widely used Make version.
> 
> > reason being that some macros and functions that I use to determine
> > absolute path, etc were not available in make 3.80.
> 
> Most of my infrastructure in test systems is based on SUSE 10.0 
> and it's impractical to upgrade make everywhere.

openSUSE 10.3 does include make-3.81.  I hope upgrading to the latest
point release won't disrupt your test systems.

http://download.opensuse.org/distribution/10.3/repo/oss/suse/x86_64/make-3.81-66.x86_64.rpm

Nate

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

On Fri, Nov 06, 2009 at 02:43:35PM -0500, Nate Straz wrote:
> On Nov  6 20:13, Andi Kleen wrote:
> > > So yes, there are known issues with using make versions <3.81. The
> > 
> > For me it seems more the known issue is in the Makefile. 3.80
> > is a widely used Make version.
> > 
> > > reason being that some macros and functions that I use to determine
> > > absolute path, etc were not available in make 3.80.
> > 
> > Most of my infrastructure in test systems is based on SUSE 10.0 
> > and it's impractical to upgrade make everywhere.
> 
> openSUSE 10.3 does include make-3.81.  I hope upgrading to the latest
> point release won't disrupt your test systems.

It does; anything udev based has unacceptable boot time penalty
with nfsroot. That's why they are still on 10.0.

-Andi

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Fri, Nov 6, 2009 at 11:59 AM, Andi Kleen <andi@firstfloor.org> wrote:
> On Fri, Nov 06, 2009 at 02:43:35PM -0500, Nate Straz wrote:
>> On Nov  6 20:13, Andi Kleen wrote:
>> > > So yes, there are known issues with using make versions <3.81. The
>> >
>> > For me it seems more the known issue is in the Makefile. 3.80
>> > is a widely used Make version.
>> >
>> > > reason being that some macros and functions that I use to determine
>> > > absolute path, etc were not available in make 3.80.
>> >
>> > Most of my infrastructure in test systems is based on SUSE 10.0
>> > and it's impractical to upgrade make everywhere.
>>
>> openSUSE 10.3 does include make-3.81.  I hope upgrading to the latest
>> point release won't disrupt your test systems.
>
> It does; anything udev based has unacceptable boot time penalty
> with nfsroot. That's why they are still on 10.0.

Andi,
    You can actually cross-compile, use out-of-build-tree and
bootstrap the system so it can effectively netboot with LTP installed.
This is something that we're doing in Cisco today, and it's something
I highly recommend doing -- especially if you have higher quality
hardware with newer OS'es doing the building for you.
    Granted, it does require more work setting everything up from
scratch, but once the work is done, it's a lot easier as far as
long-term maintenance is concerned if you're developing regularly on a
particular revisioned code-base.
    I'm more than happy to provide solutions, but they need to be
functional, stable, and easy-to-maintain longterm. Providing hacks for
make 3.80 isn't necessarily a good thing for the project to support
and it may not even solve your problem 100% (you may run into
stability issues using $(shell readlink -f "") instead of $(abspath ).
Then it comes back to tools -- I'm basically going to have to write
checks in autoconf to make sure that readlink does as planned (isn't
broken), and it's going to be more painful for you performance wise to
have this hack in place, as opposed to just having an upgraded version
of make, which also has resolved several bugs between 3.80 and 3.81.
HTH,
-Garrett

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

On Fri, Nov 06, 2009 at 12:25:23PM -0800, Garrett Cooper wrote:
>     You can actually cross-compile, use out-of-build-tree and
> bootstrap the system so it can effectively netboot with LTP installed.
> This is something that we're doing in Cisco today, and it's something
> I highly recommend doing -- especially if you have higher quality
> hardware with newer OS'es doing the building for you.

The hardware I'm using for testing is perfectly capable of
building LTP itself.

>     Granted, it does require more work setting everything up from
> scratch, but once the work is done, it's a lot easier as far as
> long-term maintenance is concerned if you're developing regularly on a
> particular revisioned code-base.

I would prefer to not get into any cross compiling mess. It would
require either static linking or maintenance of a separate build
tree with own libraries, both have many drawbacks.

>     I'm more than happy to provide solutions, but they need to be
> functional, stable, and easy-to-maintain longterm. Providing hacks for
> make 3.80 isn't necessarily a good thing for the project to support

What hacks?

make 3.80 has build whole distributions with millions of LOCs, it's unclear 
to me why it shouldn't be able to build LTP too.

I'm pretty sure that not supporting older distributions is very 
necessarily a bad thing.

> and it may not even solve your problem 100% (you may run into
> stability issues using $(shell readlink -f "") instead of $(abspath ).

I did a quick test of readlink -f and it seems to work here.

> Then it comes back to tools -- I'm basically going to have to write
> checks in autoconf to make sure that readlink does as planned (isn't
> broken), and it's going to be more painful for you performance wise to
> have this hack in place, as opposed to just having an upgraded version
> of make, which also has resolved several bugs between 3.80 and 3.81.

I don't understand: the key is not to test for commands used
by makefiles, but simply only use features which are generally available.

I'm also highly surprised that this doesn't work with autoconf -- I thought
the whole point of autoconf was to generate portable makefiles, but
in this case it seems to especially generate a non portable Makefile.

I suspect it's actually not a autoconf problem by itself, but
something that's in the LTP templates.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 509 bytes --]

On Friday 06 November 2009 16:02:25 Andi Kleen wrote:
> I'm also highly surprised that this doesn't work with autoconf -- I thought
> the whole point of autoconf was to generate portable makefiles, but
> in this case it seems to especially generate a non portable Makefile.

that is not the point of autoconf at all; it has nothing to do with makefiles.  
that is the point of automake -- which we specifically are not using.  there 
are way too many Makefiles that would need to be generated.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

On Fri, Nov 06, 2009 at 04:12:10PM -0500, Mike Frysinger wrote:
> On Friday 06 November 2009 16:02:25 Andi Kleen wrote:
> > I'm also highly surprised that this doesn't work with autoconf -- I thought
> > the whole point of autoconf was to generate portable makefiles, but
> > in this case it seems to especially generate a non portable Makefile.
> 
> that is not the point of autoconf at all; it has nothing to do with makefiles.  
> that is the point of automake -- which we specifically are not using.  there 
> are way too many Makefiles that would need to be generated.

True. So you guys just managed to write a very non portable Makefile on your
own.  Congratulations.

I tried to debug the problem, but it's such a maze that I gave up.

It seems to be related to abs_top_builddir not getting expanded correctly.

I suspect simply expanding some of the filter magic rules manually
might fix it.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Fri, Nov 6, 2009 at 1:45 PM, Andi Kleen <andi@firstfloor.org> wrote:
> On Fri, Nov 06, 2009 at 04:12:10PM -0500, Mike Frysinger wrote:
>> On Friday 06 November 2009 16:02:25 Andi Kleen wrote:
>> > I'm also highly surprised that this doesn't work with autoconf -- I thought
>> > the whole point of autoconf was to generate portable makefiles, but
>> > in this case it seems to especially generate a non portable Makefile.
>>
>> that is not the point of autoconf at all; it has nothing to do with makefiles.
>> that is the point of automake -- which we specifically are not using.  there
>> are way too many Makefiles that would need to be generated.
>
> True. So you guys just managed to write a very non portable Makefile on your
> own.  Congratulations.
>
> I tried to debug the problem, but it's such a maze that I gave up.
>
> It seems to be related to abs_top_builddir not getting expanded correctly.
>
> I suspect simply expanding some of the filter magic rules manually
> might fix it.

In summary, some of the built-in functions in 3.80 aren't implemented
/ don't work period. I need to go back and look at the documentation
and do a side-by-side comparison, but I remember that a developer
emails the help-make@gnu.org list some time back and one of the
primary Gnu make developers just flat out told him to upgrade from
3.80 to 3.81... However, we have a smaller userbase and thus I think
that we can fill in the functional gaps.

$(abspath $(FOO)) only exists in 3.81+, along with some of the other
built-in functions IIRC. Replacing $(abspath ) with $(shell readlink
-f "$(FOO)" 2>/dev/null) is possible, but there are some associated
issues with that solution:

1. They must have readlink
1. It may fail if their shell is toast (in this case, they're kind of SoL).
2. It may fail if their's a bug (that's my job to fix).

It's bad practice to use $(shell ) because it also consumes a lot more
resources allocating a separate shell, and all that badness associated
with it.

If $(patsubst ) is toast, then I'll have to replace it with $(shell )
call to awk or perl.

This can be done, and I'll work on it on Sunday and Monday. I need to
get back to my $JOB because unfortunately I have a test work to
complete.

I really do appreciate the feedback. As I stated before though, 3.80
is where we need to draw the line in the sand, because 3.79 is a
buggy, ancient PoS, so RHEL 4 users and other users of distros around
that era will _need_ to compile 3.80, or 3.81 and install it on their
target systems.

Thanks,
-Garrett

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

> $(abspath $(FOO)) only exists in 3.81+, along with some of the other
> built-in functions IIRC. Replacing $(abspath ) with $(shell readlink
> -f "$(FOO)" 2>/dev/null) is possible, but there are some associated
> issues with that solution:
> 
> 1. They must have readlink
> 1. It may fail if their shell is toast (in this case, they're kind of SoL).
> 2. It may fail if their's a bug (that's my job to fix).
> 
> It's bad practice to use $(shell ) because it also consumes a lot more
> resources allocating a separate shell, and all that badness associated
> with it.

With := it's probably not too bad to call the shell.
> 
> If $(patsubst ) is toast, then I'll have to replace it with $(shell )
> call to awk or perl.

As a datapoint the kernel uses patsubst and afaik it builds with 3.80

> I really do appreciate the feedback. As I stated before though, 3.80
> is where we need to draw the line in the sand, because 3.79 is a
> buggy, ancient PoS, so RHEL 4 users and other users of distros around
> that era will _need_ to compile 3.80, or 3.81 and install it on their
> target systems.

At least for me that works, but I don't speak for RHEL4 users.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Nate Straz]

On Nov  6 23:47, Andi Kleen wrote:
> > I really do appreciate the feedback. As I stated before though, 3.80
> > is where we need to draw the line in the sand, because 3.79 is a
> > buggy, ancient PoS, so RHEL 4 users and other users of distros around
> > that era will _need_ to compile 3.80, or 3.81 and install it on their
> > target systems.
> 
> At least for me that works, but I don't speak for RHEL4 users.

RHEL4 users have make-3.80.

Nate

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 1032 bytes --]

On Friday 06 November 2009 16:45:58 Andi Kleen wrote:
> On Fri, Nov 06, 2009 at 04:12:10PM -0500, Mike Frysinger wrote:
> > On Friday 06 November 2009 16:02:25 Andi Kleen wrote:
> > > I'm also highly surprised that this doesn't work with autoconf -- I
> > > thought the whole point of autoconf was to generate portable makefiles,
> > > but in this case it seems to especially generate a non portable
> > > Makefile.
> >
> > that is not the point of autoconf at all; it has nothing to do with
> > makefiles. that is the point of automake -- which we specifically are not
> > using.  there are way too many Makefiles that would need to be generated.
> 
> True. So you guys just managed to write a very non portable Makefile on
>  your own.  Congratulations.

"portable" is not necessarily the same thing as "works around bugs in tools".  
ignoring that, we are absolutely not "portable" -- GNU make is required.  the 
make feature set as defined by POSIX (and thus "portable") is too limited for 
our needs.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 354 bytes --]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Garrett Cooper]

On Fri, Nov 6, 2009 at 1:02 PM, Andi Kleen <andi@firstfloor.org> wrote:
> On Fri, Nov 06, 2009 at 12:25:23PM -0800, Garrett Cooper wrote:
>>     You can actually cross-compile, use out-of-build-tree and
>> bootstrap the system so it can effectively netboot with LTP installed.
>> This is something that we're doing in Cisco today, and it's something
>> I highly recommend doing -- especially if you have higher quality
>> hardware with newer OS'es doing the building for you.
>
> The hardware I'm using for testing is perfectly capable of
> building LTP itself.
>
>>     Granted, it does require more work setting everything up from
>> scratch, but once the work is done, it's a lot easier as far as
>> long-term maintenance is concerned if you're developing regularly on a
>> particular revisioned code-base.
>
> I would prefer to not get into any cross compiling mess. It would
> require either static linking or maintenance of a separate build
> tree with own libraries, both have many drawbacks.
>
>>     I'm more than happy to provide solutions, but they need to be
>> functional, stable, and easy-to-maintain longterm. Providing hacks for
>> make 3.80 isn't necessarily a good thing for the project to support
>
> What hacks?
>
> make 3.80 has build whole distributions with millions of LOCs, it's unclear
> to me why it shouldn't be able to build LTP too.
>
> I'm pretty sure that not supporting older distributions is very
> necessarily a bad thing.

I agree. There are some feature gaps between 3.80 and 3.81 I'll need
to address, which means I need to first off download SLES 10 and
install it on another VM, and toy around with it (if you can provide
me with those details, I'll give it a shot).

>> and it may not even solve your problem 100% (you may run into
>> stability issues using $(shell readlink -f "") instead of $(abspath ).
>
> I did a quick test of readlink -f and it seems to work here.
>
>> Then it comes back to tools -- I'm basically going to have to write
>> checks in autoconf to make sure that readlink does as planned (isn't
>> broken), and it's going to be more painful for you performance wise to
>> have this hack in place, as opposed to just having an upgraded version
>> of make, which also has resolved several bugs between 3.80 and 3.81.
>
> I don't understand: the key is not to test for commands used
> by makefiles, but simply only use features which are generally available.
>
> I'm also highly surprised that this doesn't work with autoconf -- I thought
> the whole point of autoconf was to generate portable makefiles, but
> in this case it seems to especially generate a non portable Makefile.
>
> I suspect it's actually not a autoconf problem by itself, but
> something that's in the LTP templates.

Agreed. The problem that everyone with <3.80 is running into is that I
was stupid and was under the assumption that many distros wouldn't
still use make 3.81 because it's been out for the past 4 years. My
apologies -- I stand corrected.

Thanks,
-Garrett

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] LTP 20091031 Makefiles totally broken?!?

[Andi Kleen]

On Fri, Nov 06, 2009 at 01:47:26PM -0800, Garrett Cooper wrote:
> > I'm pretty sure that not supporting older distributions is very
> > necessarily a bad thing.
> 
> I agree. There are some feature gaps between 3.80 and 3.81 I'll need
> to address, which means I need to first off download SLES 10 and

Sorry, it's suse 10.0, not sles10. 

But it's enough to just install make 3.80 somewhere and
call it explicitely on a newer distro (I just tested that).
Shows the same problem.

> install it on another VM, and toy around with it (if you can provide
> me with those details, I'll give it a shot).

what details do you need?

> >> Then it comes back to tools -- I'm basically going to have to write
> >> checks in autoconf to make sure that readlink does as planned (isn't
> >> broken), and it's going to be more painful for you performance wise to
> >> have this hack in place, as opposed to just having an upgraded version
> >> of make, which also has resolved several bugs between 3.80 and 3.81.
> >
> > I don't understand: the key is not to test for commands used
> > by makefiles, but simply only use features which are generally available.
> >
> > I'm also highly surprised that this doesn't work with autoconf -- I thought
> > the whole point of autoconf was to generate portable makefiles, but
> > in this case it seems to especially generate a non portable Makefile.
> >
> > I suspect it's actually not a autoconf problem by itself, but
> > something that's in the LTP templates.
> 
> Agreed. The problem that everyone with <3.80 is running into is that I

<=3.80

> was stupid and was under the assumption that many distros wouldn't
> still use make 3.81 because it's been out for the past 4 years. My
> apologies -- I stand corrected.

Thanks for addressing the problem.
I apologize also for being somewhat too grumpy on the issue.
If you have any patches to test feel free to send them.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list