Re: 319-gary-refactor-m4sh-rules

2007-03-07 Thread Gary V. Vaughan

On 6 Mar 2007, at 14:23, Ralf Wildenhues wrote:

Hello Gary,


Hallo Ralf,

Thanks for the review.


* Gary V. Vaughan wrote on Tue, Mar 06, 2007 at 08:33:50PM CET:
This makes code sharing with forthcoming func_version test cases  
easier.


Okay to commit?


IMHO this is definitely post 2.0: it doesn't fix an important bug.


It is not touching much code at all though, and without doing it this
way, I'll need to copy and paste the m4sh - in - sh rules into the  
test
case, which will mean manually keeping it all in synch, and that the  
test

itself won't actually exercise the live code.  (Not to mention that
without the patch we already have to manually synch several copies of
the same code in the existing Makefile.am implementation).


Moreover it's wrong, too: the $(srcdir) are there for a reason.
Sorry.


It was my understanding that the $(srcdir) are required on the left
of the ':' in a rule, but not on the right.  From Autoconf manual
11.13.5:

  It seems the sole solution that would please every `make'
  implementation is to never rely on `VPATH' searches for targets.  In
  other words, `VPATH' should be reserved to unbuilt sources.

If I'm correct, then I've just removed a little unnecessary fluff
from the right hand sides.  If I'm wrong, then there was already
enough inconsistency that things would have already been broken by
missing $(srcdir) on the right in other rules.  In either case, I'd
still like to commit the factoring parts of the patch.


If you're out to relax the requirement for GNU make, then I suggest
you give some information as to which make implementations you have
successfully tested with.


Nope.  Although now you mention it, I believe we're already requiring
GNU make for VPATH builds, no?  In which case, we can remove the
$(srcdir) fluff and repeated associated comments from the left side
of ':' in several rules.  The first non-GNU system I tried (on irix,
which has a SYSV4 based make) with a fresh HEAD checkout (bootstrapped
with automake-1.10, autoconf-2.60) blows up pretty fast from a VPATH
build, failing to find a source file:

  $ cd +mips-sgi-irix6.5
  $ ../configure
  [[...]]
  $ make
  [[...]]
  /bin/sh ./libtool --tag=CC--mode=compile cc -DHAVE_CONFIG_H - 
I. -I..   -DLT_CONFIG_H='config.h' -DLTDL -I. -I..  -Ilibltdl -I../ 
libltdl -I../libltdl/libltdl   -g -c -o libltdl/loaders/dlopen.lo  
libltdl/loaders/dlopen.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. - 
DLT_CONFIG_H=config.h -DLTDL -I. -I.. -Ilibltdl -I../libltdl -I../ 
libltdl/libltdl -g -c libltdl/loaders/dlopen.c  -DPIC -o libltdl/ 
loaders/.libs/dlopen.o

  cc ERROR:  file does not exist:  libltdl/loaders/dlopen.c
  *** Error code 1 (bu21)
  *** Error code 1 (bu21)
  *** Error code 1 (bu21)
  $ ls libltdl/loaders
  libltdl_libltdl_la-preopen.lo  libltdl_libltdl_la-preopen.o
  $ ls ../libltdl/loaders
  CVSdlopen.c   load_add_on.c  preopen.c
  dld_link.c dyld.c loadlibrary.c  shl_load.c

Compared to an otherwise identical in-tree build:

  $ cd ..
  $ ./configure
  [[...]]
  $ make
  [[...]]
  $ echo $?
  0
  $ gmake MAKE=gmake
  gmake  all-recursive
  gmake[1]: Entering directory `/home/gary/devel/savannah/libtool-- 
devo--0'
  gmake[2]: Entering directory `/home/gary/devel/savannah/libtool-- 
devo--0'
  gmake[2]: Leaving directory `/home/gary/devel/savannah/libtool-- 
devo--0'
  gmake[1]: Leaving directory `/home/gary/devel/savannah/libtool-- 
devo--0'


I did test pretty thoroughly with gmake from a fresh checkout with only
this patch applied and in my dev tree with just this patch applied and
leaving all the file debris from previous builds still laying around,  
with

both in-tree and VPATH builds, and I haven't introduced any regressions.


  from  Gary V. Vaughan  [EMAIL PROTECTED]
Factorize make rules used for m4sh sources:

* Makefile.am (EXTRA_DIST, libtoolize, libtool):  No need to
explicitly name $(srcdir) in dependencies, VPATH will look there
automatically.
(SUFFIXES, .m4sh.in, .m4sh.sh): New suffix rules...
($(srcdir)/tests/defs, $(srcdir)/$(auxdir)/ltmain.sh): ...factored
out from here...
($(srcdir)/tests/defs.in): ...and here.
* Makefile.maint (.SUFFIXES): Add explicitly for bootstrap, as
bootstrap's quick-n-dirty Makefile doesn't have the correct
syntax.
(.in.tmp): New suffix rule...
($(srcdir)/commit, $(srcdir)/mailnotify): ...factored out from
here.


Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912






PGP.sig
Description: This is a digitally signed message part


Re: 319-gary-refactor-m4sh-rules

2007-03-07 Thread Ralf Wildenhues
Hello Gary,

* Gary V. Vaughan wrote on Wed, Mar 07, 2007 at 09:31:58AM CET:
 On 6 Mar 2007, at 14:23, Ralf Wildenhues wrote:
 * Gary V. Vaughan wrote on Tue, Mar 06, 2007 at 08:33:50PM CET:
 This makes code sharing with forthcoming func_version test cases  
 easier.
 
 Okay to commit?
 
 IMHO this is definitely post 2.0: it doesn't fix an important bug.
 
 It is not touching much code at all though, and without doing it this
 way, I'll need to copy and paste the m4sh - in - sh rules into the  
 test case, which will mean manually keeping it all in synch, and that
 the  test itself won't actually exercise the live code.

 (Not to mention that without the patch we already have to manually
 synch several copies of the same code in the existing Makefile.am
 implementation).

Yes, certainly.  It still does not fulfill the fix only important bugs
and regressions criteria.  It simply doesn't.  If you insist, then it's
simply easier to not apply your func_version changes at all: they don't
either fix an _important_ bug.  I can certainly live well with that one
single long copyright line in ltmain.m4sh, which I'd not even qualify as
an unimportant bug, it's at most a negligible annoyance.  And if I were
to fix it, then I would make func_version more stupid by just letting it
output a constant string, and have a copy of that in each script.  I'll
anyway have to grep the source tree for several instances of '2007' next
January, the func_version automatization doesn't even avoid all that
much work for me.  But let's not discuss the bikeshed's color.

I would like for 2.1b to be released when the libltdl memory fault on
Cygwin is fixed and I've managed to put Charles' documentation patch
into a somewhat more general form.  And NEWS documents very clearly all
other regressions that we should be caring about.  If you want to add
one, then let's discuss that.  And if you have a test failure on some
system and see an easy fix, then I'm all ears, too.

But other than that, I'm simply going to have a blanket No, and it's
going to get more capitalized with time.  Let's release with all the
suboptimal and ugly and duplicated code that we have.  We've had more
than three years now where we were too lazy to fix it or not to
introduce it in the first place.  So let's live with it now.  If this
keeps going on for long, I'm going to invest less effort in saying no,
too: patch reviews take time, too, time that also pushes a release
further away.  This one for one has taken way too much of my time
already.

If the Libtool developers disagree with me here on my stance, then
by all means speak up, please.  I have postponed patches including
thorough test cases that actually have been extensively exercised, but
do not fit the above criteria.  I'd love to see these applied, but
refrain from it.  I'm also open to reconsider my Libtool commitment,
should there be irresolvable differences.

 Moreover it's wrong, too: the $(srcdir) are there for a reason.
 Sorry.
 
 It was my understanding that the $(srcdir) are required on the left
 of the ':' in a rule, but not on the right.

If you mention $(srcdir)/file as a prerequisite somewhere, then you also
have to mention it as the target.  We mentioned it with $(srcdir)/ on
the right in order to avoid surprise by Solaris make's VPATH rewriting
rules in the rule commands, IIRC.

 From Autoconf manual 11.13.5:
 
   It seems the sole solution that would please every `make'
   implementation is to never rely on `VPATH' searches for targets.  In
   other words, `VPATH' should be reserved to unbuilt sources.

Yes.  I think that supports my point.

 If I'm correct, then I've just removed a little unnecessary fluff
 from the right hand sides.  If I'm wrong, then there was already
 enough inconsistency that things would have already been broken by
 missing $(srcdir) on the right in other rules.  In either case, I'd
 still like to commit the factoring parts of the patch.

No.  Please no more factoring.  The last factoring changes cost months
if not years to get bug free.  Please pick one of the regressions if you
want to fix something.  If you rather want to fix test failures, please
say so, and I will post a couple of open ones.

 If you're out to relax the requirement for GNU make, then I suggest
 you give some information as to which make implementations you have
 successfully tested with.
 
 Nope.  Although now you mention it, I believe we're already requiring
 GNU make for VPATH builds, no?

Yes.  At the moment we do.  But we want to get away from it, users
obviously don't like the additional requirement.  So please don't make
it harder to do so in the future, by relying even more on GNU make.

 In which case, we can remove the
 $(srcdir) fluff and repeated associated comments from the left side
 of ':' in several rules.  The first non-GNU system I tried (on irix,
 which has a SYSV4 based make) with a fresh HEAD checkout (bootstrapped
 with automake-1.10, autoconf-2.60) blows up pretty fast from a 

Re: 319-gary-refactor-m4sh-rules

2007-03-07 Thread Gary V. Vaughan

On 7 Mar 2007, at 09:54, Ralf Wildenhues wrote:

Hello Gary,


Hallo Ralf,


I would like for 2.1b to be released when the libltdl memory fault on
Cygwin is fixed and I've managed to put Charles' documentation patch
into a somewhat more general form.  And NEWS documents very clearly  
all

other regressions that we should be caring about.  If you want to add
one, then let's discuss that.  And if you have a test failure on some
system and see an easy fix, then I'm all ears, too.


ACK.


But other than that, I'm simply going to have a blanket No, and it's
going to get more capitalized with time.  Let's release with all the
suboptimal and ugly and duplicated code that we have.  We've had more
than three years now where we were too lazy to fix it or not to
introduce it in the first place.  So let's live with it now.  If this
keeps going on for long, I'm going to invest less effort in saying no,
too: patch reviews take time, too, time that also pushes a release
further away.  This one for one has taken way too much of my time
already.


ACK.

Thanks again for the review.  I'll apply those changes to my patch and
maintain it in my quilt stack until post-2.0, then resubmit.


No.  Please no more factoring.  The last factoring changes cost months
if not years to get bug free.  Please pick one of the regressions  
if you
want to fix something.  If you rather want to fix test failures,  
please

say so, and I will post a couple of open ones.


I'll start by making the longhand changes to the copyright notices I
posted here:

   http://lists.gnu.org/archive/html/libtool-patches/2007-02/ 
msg00146.html


And then I'll help work on regressions and testing for 2.0.

We can merge all the changes from the masters of getopt.m4sh and
general.m4sh somewhere down the line.

Cheers,
Gary
--
  ())_.  Email me: [EMAIL PROTECTED]
  ( '/   Read my blog: http://blog.azazil.net
  / )= ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912






PGP.sig
Description: This is a digitally signed message part


mdemo ltdl failure (was: export.at failure on MinGW)

2007-03-07 Thread Ralf Wildenhues
A (very small) progress report. 


On Tue, Feb 27, 2007 at 11:02:01PM +0100, Ralf Wildenhues wrote:

* Charles Wilson wrote on Tue, Feb 27, 2007 at 05:42:50AM CET:
 Ralf Wildenhues wrote: 


 The only thing that's then still worrying me is that on Cygwin, the
 mdemo and mdemo_static programs sometimes throw segmentation faults
 on my system.  Not all the time though.
 
 Well, it's failing all the time for me, but I'm not sure it's a 
 segfault. What does Hangup mean, when reported by the shell after 
 executing the app: 


Good question, I don't know.  I suppose there is memory corruption
earlier, and due to it anything weird can happen later, so the exit
status is not really reliable.


It's exposed by try_iterate which calls lt_dlforeachfile.  I think it's
somewhere in dirent code.  I have a feeling that it's not caused by
anything in Libtool, but am not sure.  (Only noting this because it may
ring a bell, not because I have any evidence.) 


This works:
$ mdemo/mdemo mdemo/foo1.la
$ mdemo/mdemo `pwd`/mdemo/foo1.la 


This fails:
$ mdemo/mdemo ./mdemo/foo1.la 


Cheers,
Ralf