Re: branch-2-0 vs CVS HEAD
Hi Gary, * Gary V. Vaughan wrote on Sun, Aug 28, 2005 at 11:56:31PM CEST: On 22 Aug 2005, at 21:00, Gary V. Vaughan wrote: Ralf Wildenhues wrote: Furthermore, it has at least this serious bug in its new functionality: - using libltdl but not as subpackage does not work as advertised (this bug is in part a documentation bug -- LTDL_INIT needs to be suitably documented -- but also the AC_CONFIG_SUBDIRS call from LT_WITH_LTDL needs to be made configurable) Hmm... I'll look into this when --patch-23 is resolved. This concern was just because cvs diff hadn't picked up all of -- patch-23 right? Everything seems to work fine here... No. Regardless, LTDL_INIT is not documented at the moment, and I'm not sure we want to explicitly support use of libltdl except as a subpackage. Although it has been possible to do so for quite some time (if only because libtool itself has done so on and off over the last few years), we have never really *designed* an interface for it. Post-2.0, we can always firm up a long term interface, document it and *then* make a commitment to support that interface in the future. I don't understand this paragraph at all. From what I could gather, this was one of *the* new features to be advertised for the next stable version. When Bob reported several times that it was nonfunctional, never was there a reply of yours stating this wasn't intended feature. While I can see you backing up because you want to move closer to this release, I cannot understand how you can argue now that this was not a feature users should be able to profit from. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Hallo Ralf,
On 29 Aug 2005, at 12:43, Ralf Wildenhues wrote:
Hi Gary,
private mail on purpose?
Nup, my MUA is playing silly buggers. :-( Might go back to webmail
until
I've had chance to configure Thunderbird the way it's behaving atm! Grr.
[Quoting everything for the sake of readers on the list.]
* Gary V. Vaughan wrote on Mon, Aug 29, 2005 at 12:38:50PM CEST:
On 29 Aug 2005, at 07:29, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Sun, Aug 28, 2005 at 11:56:31PM CEST:
Regardless, LTDL_INIT is not documented at the moment, and I'm not
sure we want to explicitly support use of libltdl except as a
subpackage. Although it has been possible to do so for quite some
time (if only because libtool itself has done so on and off
over the
last few years), we have never really *designed* an interface
for it.
Post-2.0, we can always firm up a long term interface, document it
and
*then* make a commitment to support that interface in the future.
I don't understand this paragraph at all. From what I could gather,
this was one of *the* new features to be advertised for the next
stable
version.
If I have touted this as a feature, I've forgotten. Mea culpa.
Actually, I don't /know/ whether you did that, or I just always
understood wrongly. At least it seems Bob misunderstood then, too.
Good point.
When Bob reported several times that it was nonfunctional,
never was there a reply of yours stating this wasn't intended
feature.
It certainly ought to work, because libtool itself is using it.
Libtool is not using LT_WITH_LTDL in $top_srcdir/configure.ac.
But client packages need to have the additional configure switches and
logic which is only triggered by LT_WITH_LTDL.
If OTOH you add LT_WITH_LTDL to configure.ac, at least the
AC_CONFIG_SUBDIRS at its end breaks libltdl-as-non-subpackage.
Was this bug description halfway understandable?
Yep. Thanks.
While I can see you backing up because you want to move closer to
this
release, I cannot understand how you can argue now that this was
not a
feature users should be able to profit from.
I am backing up because I want to release 2.0 asap. On reflection, I
can't see any problem with supporting the current API for the
forseeable future. I'll work on a doc patch today.
Please keep the above in mind. It would be very cool if this could be
made to work.
Sure.
Cheers,
Gary.
--
Gary V. Vaughan ())_. gary@
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]
Research Scientist ( '/ http://www.tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/{libtool,m4}
Technical Author `(_~)_ http://sources.redhat.com/autobook
PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
On Mon, 29 Aug 2005, Ralf Wildenhues wrote: Regardless, LTDL_INIT is not documented at the moment, and I'm not sure we want to explicitly support use of libltdl except as a subpackage. Although it has been possible to do so for quite some time (if only because libtool itself has done so on and off over the last few years), we have never really *designed* an interface for it. Post-2.0, we can always firm up a long term interface, document it and *then* make a commitment to support that interface in the future. I don't understand this paragraph at all. From what I could gather, this was one of *the* new features to be advertised for the next stable version. When Bob reported several times that it was nonfunctional, never was there a reply of yours stating this wasn't intended feature. Yes, it was intended to be one of the main new features of libtool 2.0. If it is not documented now, then someone has deleted some documentation since there was certainly some (poor) documentation added to describe it after Gary did the work in February 2003 and announced it to the world. Unfortunately, the work was not yet to a finished/tested state. The plan is that packages using libltdl 2.0 can configure libltdl using their own configure script. This reduces configure run time by about a factor of two and also reduces the amount of configure script code by a factor of two. Reducing configuration time by a factor of two is a huge win. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Hallo Ralf,
On 22 Aug 2005, at 21:00, Gary V. Vaughan wrote:
Ralf Wildenhues wrote:
Furthermore, it has at least this serious bug in its new
functionality:
- using libltdl but not as subpackage does not work as advertised
(this bug is in part a documentation bug -- LTDL_INIT needs to be
suitably documented -- but also the AC_CONFIG_SUBDIRS call from
LT_WITH_LTDL needs to be made configurable)
Hmm... I'll look into this when --patch-23 is resolved.
This concern was just because cvs diff hadn't picked up all of --
patch-23
right? Everything seems to work fine here...
Regardless, LTDL_INIT is not documented at the moment, and I'm not
sure we
want to explicitly support use of libltdl except as a subpackage.
Although
it has been possible to do so for quite some time (if only because
libtool
itself has done so on and off over the last few years), we have never
really *designed* an interface for it. Post-2.0, we can always firm up a
long term interface, document it and *then* make a commitment to support
that interface in the future.
Cheers,
Gary.
--
Gary V. Vaughan ())_. gary@
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]
Research Scientist ( '/ http://www.tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/{libtool,m4}
Technical Author `(_~)_ http://sources.redhat.com/autobook
PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary V. Vaughan wrote: | | Hear! Hear! | | | Blast. Seems I'm outvoted. To my mind there are good arguments for | either case... but I'm not rabid about keeping branch-2-0 alive, so if | the concensus is to drop the current branch-2-0 then so be it. Anyone | else want to weigh in before anything is settled upon firmly? While there are some new features in HEAD that are not in branch-2-0, I don't believe them to be destabalizing. Ralf's speedups by themselves are, in my opinion, worth the pain of dumping current branch-2-0 for HEAD. The other new features include the testsuite, which has also proven its worth. Sorry Gary, branch-2-0 was branched with a release in sight, a couple of weeks, but that was a very long time ago... Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQwxrX7iDAg3OZTLPAQK+hQP/cvrVOwY+4p3Fa8luqHNjOrRnWDXOwhPf /Qm8lNCPegCa+7c8wlFK3Az6pQC3r9mT0wlG4UjFHaq1X804otW1TtdbPz1fjAuP kP2WEZE/KruQ0pjU1G96LLMljDklSAljDUaEpoadK0Y+m8PKxNo/cwZ6E9fmo9Bl dYatSzjUHNk= =ZmfD -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
* Albert Chin wrote on Tue, Aug 23, 2005 at 04:41:58AM CEST: On Mon, Aug 22, 2005 at 07:54:59PM +0100, Gary V. Vaughan wrote: Ralf Wildenhues wrote on libtool-patches: I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. The showstopper for this plan is that libtool is holding up the next release of all the other autotools[1], so we can't release HEAD as is without causing headaches for everyone else, because it relies on unreleased versions of the tools that are waiting for another libtool release. libtool-2.0 should not rely on newer autoconf/automake. People simply won't adopt it. RHEL 4 ships with autoconf-2.59 and automake-1.9.2. I'm not against requiring the latest, as of now, autoconf/automake, but relying on autoconf-2.60 and automake-1.10 seems way too aggressive. Good argument. But the two questions are almost orthogonal: Practically speaking, if the point is that branch-2-0 is to receive all backported regression fixes HEAD sees now, and then revert to subpackage libltdl so that it works with released autotools -- which branch-2-0 doesn't do now, right? -- then it's *still* a lot less work to fork the release right off of current CVS HEAD after that has been fixed, and it gives us a lot better test coverage. So my point is: get HEAD stable now, then branch off and make 2.59/1.9.6 compatible there. Then bootstrap the release with the couple of naughty system-dependent fixes we know of in those autotools versions. Am I missing anything? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
TODO for 2.x (was: branch-2-0 vs CVS HEAD)
* Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 10:00:50PM CEST: Is there a public record of these? TODO file? Search string for the list archives? next mail in this thread? ;-) The following is not very well ordered, not very well cross-referenced, has nonempty overlap with the in-tree TODO file (sorry), is not complete (complain!), and some items served mainly as reminders for me so far. I might add some URLs and replace the MsgIDs if you put this in an editable format. Most applies to branch-2-0/HEAD or all branches. branch-1-5 only issues are denoted as such. STOP! Yes, you, right there! Before you comment on specific items below or add new ones: Please adjust the Subject: accordingly, and keep specific issues in their subthreads! Not another monster thread where information is not to be found again! (Alternatively: Gary, how about a publicly editable version of this?) Cheers, Ralf regressions === - use AH_HEADER (when Autoconf has it) so we are compatible to both 2.59 and CVS, and do not use private and wrong macros which break on ltdl-using client packages. pending. - fix `make install' and ltdl files timestamps. pending. - Fix LTDL_CONVENIENCE and STATIC/SHARED stuff! (mails by Akim, Albert) - Does the client need argz.m4? Only if libtoolize --ltdl? - win32-dll issue: is this the correct patch? http://lists.gnu.org/archive/html/libtool/2005-03/msg00158.html - fix func_show_eval (or something along the way) shows not what is correctly executed (see $NM -BCpg on AIX). minor bug, description pending. - double elements in configure --help (I may removed (the wrong?) one in a patch against configure.ac) - we define LT_OBJDIR unconditionally for client sources, but don't need to (only for ltdl). - Peter Ekberg: m4_require(_LT_TAG_COMPILER) in LT_PATH_NM. minor bug, fix pending. non-system dependent - Use a better bug tracking system than this stupid list + mail folder. - LTDL_INIT/LT_WITH_LTDL: document, allow optional AC_CONFIG_SUBDIRS. - fix order of macros for non-C++ users of HIDDEN_DEPLIBS: _LT_SYS_HIDDEN_LIBDEPS is at broken position in _LT_LANG_FC_CONFIG and F77 should be after _LT_LINKER_SHLIBS because output_verbose_link.. - allow --prefer-duplicate-deps after $CC - fix Keith Packard's different SONAME patch; test, apply - Derek Price: allow spaces in paths. find a way to get this without breaking compatibility! - deplink DESTDIR install failure. related: destdir rpath [EMAIL PROTECTED] - relink outside build tree (below DESTDIR/prefix?) - relink even less often when possible - check whether the temp rpath fix leaves cwd (`.') in LD_LIBRARY_PATH - do not leave build-tree references in installed .la files if not all libs are libtool-created (GCC!) (technically a limitation) - fix java m4 section, seriously broken - write test for $ in filenames, allow $ in object names - implement --quiet --quiet (no output) - s/EOF/_LTEOF/ in our macros (ltdl.m4). pending. - fix LN_S use. pending. - fix use of `#' in Makefiles system-dependent - Fix the Solaris CC -no-undefined issue _right_. - C++ with templates need work (basic support in HEAD only) for: Solaris (-xar?), IRIX (see post from Albert), others - Ralf Menzel: branch-2-0 rebootstrap? (Solaris issue? Maybe already fixed?) - Detect shortcut RANLIB if possible, use `ar -S' with piecewise archive linking, if it works (see message by Alexandre Oliva) - Fix static libltdl using dlopen on some BSD versions (reported by Guilhem Lavaux) - Fix AIX -dlopen self - make link-order SKIP or work on AIX. - AIX .funcname() problem. Need a testcase. [EMAIL PROTECTED] (maybe fixed in branch-2-0?) - backport AIX fixes to branch-1-5. - hide AIX chmod warning. pending. - Dan Stromberg: improve AIX support. - Work around some weird issues with non-GNU `make' triggering autotools reruns (seen on cygwin and mingw). - mingw mdemo failures pending: Peter Ekberg's patches [EMAIL PROTECTED] [EMAIL PROTECTED] - fix lt_error_strings on mingw more general: kill all non-function interfaces! (also those in symbols-list-object!) - cygwin -export-dynamic + -export-symbols failure. [EMAIL PROTECTED] - fix stresstest failures on cygwin/mingw - have cwrapper fail if exec fails (look at gettext diff against libtool, has more changes.) - test, apply MSVC support discuss naming scheme lib$name vs $name see also e.g. https://sourceforge.net/forum/message.php?msg_id=3303527 - forward port Interix patch, test, apply - Tru64: work around shell bugs when executing `libtool' (branch-2-0/HEAD) - Fix F77/FC support for ifort/ifc -static - Fix finding icc/icpc rules when -no-gcc is not given - Fix some weird compile/link behavior (reported by Jeremie Le Hen) - Kill pass_all on many systems! But also improve library search algo to be more like local compiler - PR/17311: Wrong libgcc_s.so.1 is used by lt-gij
Re: branch-2-0 vs CVS HEAD
On Tue, Aug 23, 2005 at 08:11:48AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Tue, Aug 23, 2005 at 04:41:58AM CEST: On Mon, Aug 22, 2005 at 07:54:59PM +0100, Gary V. Vaughan wrote: Ralf Wildenhues wrote on libtool-patches: I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. The showstopper for this plan is that libtool is holding up the next release of all the other autotools[1], so we can't release HEAD as is without causing headaches for everyone else, because it relies on unreleased versions of the tools that are waiting for another libtool release. libtool-2.0 should not rely on newer autoconf/automake. People simply won't adopt it. RHEL 4 ships with autoconf-2.59 and automake-1.9.2. I'm not against requiring the latest, as of now, autoconf/automake, but relying on autoconf-2.60 and automake-1.10 seems way too aggressive. ... So my point is: get HEAD stable now, then branch off and make 2.59/1.9.6 compatible there. Then bootstrap the release with the couple of naughty system-dependent fixes we know of in those autotools versions. Seems fine to me. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Albert Chin wrote: On Tue, Aug 23, 2005 at 08:11:48AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Tue, Aug 23, 2005 at 04:41:58AM CEST: On Mon, Aug 22, 2005 at 07:54:59PM +0100, Gary V. Vaughan wrote: Ralf Wildenhues wrote on libtool-patches: I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. The showstopper for this plan is that libtool is holding up the next release of all the other autotools[1], so we can't release HEAD as is without causing headaches for everyone else, because it relies on unreleased versions of the tools that are waiting for another libtool release. libtool-2.0 should not rely on newer autoconf/automake. People simply won't adopt it. RHEL 4 ships with autoconf-2.59 and automake-1.9.2. I'm not against requiring the latest, as of now, autoconf/automake, but relying on autoconf-2.60 and automake-1.10 seems way too aggressive. ... So my point is: get HEAD stable now, then branch off and make 2.59/1.9.6 compatible there. Then bootstrap the release with the couple of naughty system-dependent fixes we know of in those autotools versions. Seems fine to me. I'm still uncomfortable with this, because we have been commiting patches to HEAD that were deemed too destabilizing for branch-2-0, and I (for one) don't remember what they were... We have things backwards right now. We should be working on getting branch-2-0 stable right now, and forward porting any patches generated in so doing to HEAD. The only reason things have tilted the other way recently is that we have both been working on big patches that were easier to verify by adding tests to the new testsuite. *Conceptually*, even these big patches are for branch-2-0, we just happened to develop them in the nicer non-frozen HEAD environment. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
* Gary V. Vaughan wrote on Tue, Aug 23, 2005 at 04:03:20PM CEST: Albert Chin wrote: On Tue, Aug 23, 2005 at 08:11:48AM +0200, Ralf Wildenhues wrote: So my point is: get HEAD stable now, then branch off and make 2.59/1.9.6 compatible there. Then bootstrap the release with the couple of naughty system-dependent fixes we know of in those autotools versions. Seems fine to me. I'm still uncomfortable with this, because we have been commiting patches to HEAD that were deemed too destabilizing for branch-2-0, and I (for one) don't remember what they were... Surely there are a few patches which seemed unsafe and a few features we still might want to change. The first have had quite a bit of testing exposure. We can mark a couple of the second experimental and bound to change. We have things backwards right now. We should be working on getting branch-2-0 stable right now, and forward porting any patches generated in so doing to HEAD. The only reason things have tilted the other way recently is that we have both been working on big patches that were easier to verify by adding tests to the new testsuite. *Conceptually*, even these big patches are for branch-2-0, we just happened to develop them in the nicer non-frozen HEAD environment. I believe you just contradicted yourself. If you put big patches into a release branch, you're by definition _not_ stabilizing it! More to the point: both the recent commits to HEAD as well as their backports to branch-2-0 will most likely introduce new bugs, huge as the patches are! I'm especially afraid of the bugs introduced by the backporting process. Now, our branch-2-0 testsuite is much inferior, so it's less likely to _find_ some of these bugs. Add to that the fact that I for one do not know of one single bug present in HEAD but not in branch-2-0. This is why I would branch the next stable off of HEAD. And I wouldn't do it _yet_, but only when all known regressions from HEAD are fixed and we can start undoing whatever made CVS Autoconf/Automake necessary. And when we finally do that, we have a chance to *really* make it a couple of weeks (2!) from branching to releasing an alpha, and then 2 more to releasing. Remember that we agreed once that a stable branch per definition should not need to see any increases in the serial number of the m4 macro files? This was a prerequisite to having the stable branch not overtake another development branch. This was one reason I have rejected all interface changes to branch-1-5. For example, with branch-2-0, we cannot hold this promise any more and at the same time get our current changes backported. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
On Tue, 23 Aug 2005, Ralf Wildenhues wrote: Now, our branch-2-0 testsuite is much inferior, so it's less likely to _find_ some of these bugs. Add to that the fact that I for one do not know of one single bug present in HEAD but not in branch-2-0. This is why I would branch the next stable off of HEAD. And I wouldn't do it _yet_, but only when all known regressions from HEAD are fixed and we can start undoing whatever made CVS Autoconf/Automake necessary. And when we finally do that, we have a chance to *really* make it a couple of weeks (2!) from branching to releasing an alpha, and then 2 more to releasing. Hear! Hear! Release branches are supposed to be there to support releases, not hard-core development. Instead, the 2.0 branch has been used for hard-core development with an immense amount of patching. I think it may be 1-1/2 years old now. In my opinion, if after creating a release branch, a stable release can't be prepared within a couple of weeks, then there is something *dreadfully wrong*. The software should be stabilized *before* the branch is created. The 2.0 branch should have been aborted at that time. During this whole time, the 2.0 branch has acted like a parasite and has sucked much of the life out of the project. Because of the extreme delay with the 2.0 branch, it became necessary to continue maintenance of the 1.5.X branch (which was supposed to stop at 1.5.2, not continue on to 1.5.20). And of course there was also significant development on HEAD. So the end result is that we have *three* libtool projects requiring *three* times the maintenance, and *three* times the volume of patch emails. Only very dedicated maintainers are able to keep up with three similar projects at the same time. I totally agree that the quality of the test suite defines the quality of the product, provided that the product passes the test suite. Quite often, things which are not tested, are broken. A better test suite leads to a better product. If HEAD has a much better test suite than 2.0 and is passing its tests on many platforms, then it is naturally a better product. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Hallo Ralf, Ralf Wildenhues wrote: I believe you just contradicted yourself. I'm good at that :-) But you have to really pay attention to catch me out! :-p If you put big patches into a release branch, you're by definition _not_ stabilizing it! More to the point: both the recent commits to HEAD as well as their backports to branch-2-0 will most likely introduce new bugs, huge as the patches are! I'm especially afraid of the bugs introduced by the backporting process. That is true post release. However, we haven't yet made a release and unfortunately some of the bugs we are shaking out required big patches to correct them :-( Now, our branch-2-0 testsuite is much inferior, so it's less likely to _find_ some of these bugs. Add to that the fact that I for one do not know of one single bug present in HEAD but not in branch-2-0. Agreed. This is why I would branch the next stable off of HEAD. And I wouldn't do it _yet_, but only when all known regressions from HEAD are fixed and we can start undoing whatever made CVS Autoconf/Automake necessary. And when we finally do that, we have a chance to *really* make it a couple of weeks (2!) from branching to releasing an alpha, and then 2 more to releasing. It's the find whatever needs CVS Autofoo and find experimental changes parts of this plan that bother me... Remember that we agreed once that a stable branch per definition should not need to see any increases in the serial number of the m4 macro files? This was a prerequisite to having the stable branch not overtake another development branch. This was one reason I have rejected all interface changes to branch-1-5. For example, with branch-2-0, we cannot hold this promise any more and at the same time get our current changes backported. Again, I think that is only true after a release has been made. It will be ugly to bump the serials on HEAD just to make sure they are higher than the numbers used in the first actual release from branch-2-0, but it is a small price to pay for ferreting through ChangeLogs, cvs logs and mailing lists trying to figure out what we need to pull from HEAD to make it look like branch-2-0! (Once we have agreed on a policy for this we ought to document it in HACKING btw.) By my own arguments I can see that it follows that backporting the new autotests to branch-2-0 is perhaps the best compromise? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Hi Bob! Bob Friesenhahn wrote: On Tue, 23 Aug 2005, Ralf Wildenhues wrote: Now, our branch-2-0 testsuite is much inferior, so it's less likely to _find_ some of these bugs. Add to that the fact that I for one do not know of one single bug present in HEAD but not in branch-2-0. This is why I would branch the next stable off of HEAD. And I wouldn't do it _yet_, but only when all known regressions from HEAD are fixed and we can start undoing whatever made CVS Autoconf/Automake necessary. And when we finally do that, we have a chance to *really* make it a couple of weeks (2!) from branching to releasing an alpha, and then 2 more to releasing. Hear! Hear! Blast. Seems I'm outvoted. To my mind there are good arguments for either case... but I'm not rabid about keeping branch-2-0 alive, so if the concensus is to drop the current branch-2-0 then so be it. Anyone else want to weigh in before anything is settled upon firmly? Release branches are supposed to be there to support releases, not hard-core development. Instead, the 2.0 branch has been used for hard-core development with an immense amount of patching. I think it may be 1-1/2 years old now. In my opinion, if after creating a release branch, a stable release can't be prepared within a couple of weeks, then there is something *dreadfully wrong*. The software should be stabilized *before* the branch is created. The 2.0 branch should have been aborted at that time. I disagree. There was definitely a need for somewhere to commit new features that didn't belong in 2.0, and traditionally HEAD is where that happens. I think the release branch should be made at feature freeze, and bugs worked on in the release branch without stalling development in HEAD. During this whole time, the 2.0 branch has acted like a parasite and has sucked much of the life out of the project. Because of the extreme delay with the 2.0 branch, it became necessary to continue maintenance of the 1.5.X branch (which was supposed to stop at 1.5.2, not continue on to 1.5.20). And of course there was also significant development on HEAD. So the end result is that we have *three* libtool projects requiring *three* times the maintenance, and *three* times the volume of patch emails. Only very dedicated maintainers are able to keep up with three similar projects at the same time. ACK. Maybe the way to go when faced with this decision again for 2.2 should be to create a development branch that is merged back in when branch-2-2 is forked from HEAD? Man CVS is the pits! I totally agree that the quality of the test suite defines the quality of the product, provided that the product passes the test suite. Quite often, things which are not tested, are broken. A better test suite leads to a better product. If HEAD has a much better test suite than 2.0 and is passing its tests on many platforms, then it is naturally a better product. ACK. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
branch-2-0 vs CVS HEAD (was: Libtool: Microsoft dumpbin as name lister)
Hi Peter, * Peter Ekberg wrote on Mon, Aug 22, 2005 at 02:10:14PM CEST: Ralf Wildenhues wrote: * Peter Ekberg wrote on Thu, Aug 18, 2005 at 02:36:47PM CEST: | +lt_cv_sys_global_symbol_pipe=$SED -n -e '/ UNDEF [^|]*()/d; / 00* UNDEF /d; I think you are missing a pair of brackets here: ^^^ [[^|]] Good eyes! I'm almost certain I had that, at least at some point. Must have gone missing in some manual backport from a working version of ltmain.sh... The long waits during `bootstrap' are well spent reading. Thanks for (all) your review(s)! Well, sure. I'd also like to add (to Bob's statement) that I believe you do important work. I'm sorry I did not get to any of your other patches this weekend. Applied, can I also apply to branch-2-0? Hmm. I'm all for fixing all known issues in HEAD first. When we have finally fixed installation and ltdl issues in CVS HEAD, and you have finally installed all of your MSVC work, then: - backporting everything will still be a lot of work, - testing the backports will be even more work, plus nobody will actually do it, or it won't be exposed, because: - CVS HEAD is IMNSHO actually much more tested than branch-2-0 ATM, for one because it has a much larger set of tests, and for another because I test several systems regularly, - backporting all of the test suite would be even more work. :-/ I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. Now I estimate that, for us combined, it might save us a man month (whoohoo, maybe even a mythical one :) or more. This would be a strong argument to do it, IMVHO. The only problem is: I don't know how we can get CVS HEAD to work fine with released Autoconf/Automake versions. ATM I'm not even sure which issues there are: - LTLIBOBJS in subdirs - ? Of course the new test suite would even be better with the enhancements of CVS Autoconf. But oh well. We could release it bootstrapped with CVS versions of autotools. I believe users of libltdl that - either build it as subpackage, - or as integrated package but with sub-Makefile.am, still won't be hurt. But we'd need to test that as well. Cheers, Ralf
Re: branch-2-0 vs CVS HEAD
[Moved to libtool list] Ralf Wildenhues wrote on libtool-patches: I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. Now I estimate that, for us combined, it might save us a man month (whoohoo, maybe even a mythical one :) or more. This would be a strong argument to do it, IMVHO. The only problem is: I don't know how we can get CVS HEAD to work fine with released Autoconf/Automake versions. ATM I'm not even sure which issues there are: - LTLIBOBJS in subdirs - ? The showstopper for this plan is that libtool is holding up the next release of all the other autotools[1], so we can't release HEAD as is without causing headaches for everyone else, because it relies on unreleased versions of the tools that are waiting for another libtool release. branch-2-0 doesn't need to be perfect before we release it -- as long as it has no known regressions, and good backwards compatibility, then we can work out the wrinkles in patch releases. I'm genuinely optimistic that we can release 1.9h within 2 weeks, possibly less. And maybe 2.0 can follow the week after if we've done a good job of testing. Cheers, Gary. [1] Autoconf-2.60 needs M4-2.0 needs Libtool-2.0 (ISTR that Automake-1.10 is waiting on something here too, but I can't find a record of it in the archives). -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Hi Gary, * Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 08:54:59PM CEST: [Moved to libtool list] Thanks. Ralf Wildenhues wrote on libtool-patches: I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. The only problem is: I don't know how we can get CVS HEAD to work fine with released Autoconf/Automake versions. ATM I'm not even sure which issues there are: The showstopper for this plan is that libtool is holding up the next release of all the other autotools[1], so we can't release HEAD as is without causing headaches for everyone else, because it relies on unreleased versions of the tools that are waiting for another libtool release. I have not understood the exact nature of the dependencies, I guess. branch-2-0 doesn't need to be perfect before we release it -- as long as it has no known regressions, and good backwards compatibility, then we can work out the wrinkles in patch releases. The problem is that CVS HEAD still *has* regressions: - enabling/disabling static/shared libs is broken - doing so for individual libs in the package is broken (when using the 1.5.x macro names) (maybe actually committing your AU_ALIAS patch 2005-05-07 would help?) Furthermore, it has at least this serious bug in its new functionality: - using libltdl but not as subpackage does not work as advertised (this bug is in part a documentation bug -- LTDL_INIT needs to be suitably documented -- but also the AC_CONFIG_SUBDIRS call from LT_WITH_LTDL needs to be made configurable) Then there are a bunch of smaller, mostly system-dependent issues, which I personally would be happy with working on past a release. branch-2-0 has these regressions as well (plus currently a couple more). I'm genuinely optimistic that we can release 1.9h within 2 weeks, possibly less. And maybe 2.0 can follow the week after if we've done a good job of testing. Then there is one thing I don't understand: How can you get 2.0 to work with Autoconf-2.59 and Automake-1.9.6, if that isn't possible with CVS HEAD? Either I'm misunderstanding, or you'll just have to find a new set of fixes for branch-2-0 than for CVS HEAD, because those all rely on newer Autoconf/Automake. [1] Autoconf-2.60 needs M4-2.0 needs Libtool-2.0 Why does Autoconf-2.60 need M4-2.0, BTW? (ISTR that Automake-1.10 is waiting on something here too, but I can't find a record of it in the archives). I see this whole issue as another reason to push for regular point releases, and general releases more often. I like the fact that Automake has had the former up to now. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
On Mon, Aug 22, 2005 at 07:54:59PM +0100, Gary V. Vaughan wrote: [1] Autoconf-2.60 needs M4-2.0 needs Libtool-2.0 (ISTR that For what does Autoconf need M4 2.0? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Hallo Ralf, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 08:54:59PM CEST: Ralf Wildenhues wrote on libtool-patches: I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. The only problem is: I don't know how we can get CVS HEAD to work fine with released Autoconf/Automake versions. ATM I'm not even sure which issues there are: The showstopper for this plan is that libtool is holding up the next release of all the other autotools[1], so we can't release HEAD as is without causing headaches for everyone else, because it relies on unreleased versions of the tools that are waiting for another libtool release. I have not understood the exact nature of the dependencies, I guess. That's okay, I forget the details too... except that I keep getting bashed for holding up M4-2.0 by Stepan and Akim! branch-2-0 doesn't need to be perfect before we release it -- as long as it has no known regressions, and good backwards compatibility, then we can work out the wrinkles in patch releases. The problem is that CVS HEAD still *has* regressions: - enabling/disabling static/shared libs is broken - doing so for individual libs in the package is broken (when using the 1.5.x macro names) Gah... http://tkd.kicks-ass.net/WebWiki/GnuLibtoolProject/BugReports/ needs a record of these so I don't forget again... (maybe actually committing your AU_ALIAS patch 2005-05-07 would help?) I still have other outstanding patches? Heck, guess I need to check for unmerged stuff in [EMAIL PROTECTED]/libtool--gary--1.0! Furthermore, it has at least this serious bug in its new functionality: - using libltdl but not as subpackage does not work as advertised (this bug is in part a documentation bug -- LTDL_INIT needs to be suitably documented -- but also the AC_CONFIG_SUBDIRS call from LT_WITH_LTDL needs to be made configurable) Hmm... I'll look into this when --patch-23 is resolved. Then there are a bunch of smaller, mostly system-dependent issues, which I personally would be happy with working on past a release. Is there a public record of these? TODO file? Search string for the list archives? next mail in this thread? ;-) branch-2-0 has these regressions as well (plus currently a couple more). Same questions. I'm genuinely optimistic that we can release 1.9h within 2 weeks, possibly less. And maybe 2.0 can follow the week after if we've done a good job of testing. Okay, I'll take that back. I thought patch-23 was the last regression :-( Then there is one thing I don't understand: How can you get 2.0 to work with Autoconf-2.59 and Automake-1.9.6, if that isn't possible with CVS HEAD? Either I'm misunderstanding, or you'll just have to find a new set of fixes for branch-2-0 than for CVS HEAD, because those all rely on newer Autoconf/Automake. branch-2-0 doesn't currently need CVS autotools (just lightly patched 2.59 and 1.9.6). I can backport patch-23 without changing that. [1] Autoconf-2.60 needs M4-2.0 needs Libtool-2.0 Why does Autoconf-2.60 need M4-2.0, BTW? I forget. Perhaps it was needing to be able to change the macro search path from m4 code? Someone on the Autoconf list will remember. (ISTR that Automake-1.10 is waiting on something here too, but I can't find a record of it in the archives). Actually, I think automake was waiting on the m4 macro search path improvements, and autoconf-2.60 needs automake-1.10. Someone on the Automake list will remember. I see this whole issue as another reason to push for regular point releases, and general releases more often. I like the fact that Automake has had the former up to now. Agreed. Also a reason why none of the tools should make a stable release that needs a CVS revision of any of the others. Actually, we are doing good in respect of point releases with our stable 1.5 branch, and in respect of CVS revision dependencies with our future stable 2.0 branch. *And* we are doing a better job of backward compatibility than either Automake or Autoconf have historically. :-D Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
