You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
(8) |
Mar
(53) |
Apr
(2) |
May
(14) |
Jun
(15) |
Jul
(13) |
Aug
(2) |
Sep
|
Oct
|
Nov
(9) |
Dec
|
2003 |
Jan
(1) |
Feb
(9) |
Mar
(25) |
Apr
(17) |
May
(87) |
Jun
(30) |
Jul
(21) |
Aug
(4) |
Sep
(46) |
Oct
(15) |
Nov
(2) |
Dec
(62) |
2004 |
Jan
(65) |
Feb
(31) |
Mar
(6) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(4) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(17) |
2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: fess <fe...@ov...> - 2004-02-05 00:35:51
|
awesome, thanks. don't know how I missed that. I was specifically looking to disable csharp. --fess On Feb 4, 2004, at 4:15 PM, Dave Benson wrote: > i believe we want a package > gettext-runtime > which we can have by: > configure_subdir=gettext-runtime > configure_options=--disable-csharp > anyways, that built for me... > > (only translators need the other parts of gettext, > so let's omit them...) > > see the PACKAGING file in gettext for a few details... > > - dave > > On Wed, Feb 04, 2004 at 03:30:24PM -0800, fess wrote: >> >> >> Hey, I've noticed that glib2 needs gettext to be installed: >> >> Finally, for message catalog handling, GTK+ requires an >> implementation >> of gettext(). If your system doesn't provide this functionality, >> you should use the libintl library from the GNU gettext package, >> >> It turns out that (at least) the latest version of gnu gettext >> requires, a c# compiler to compile it CIL hooks or something. >> so, installing pnet, or mono as a dependancy of gettext, seems a >> little >> excessive, does anyone have any ideas? >> >> >> I was hoping glib2 could be compiled without gettext, but it doesn't >> look like it. Also, I was hoping that possibly gettext could be >> compiled >> without the c# stuff, but there's not an obvious option. I might >> be able to patch it, to do this. >> >> any thoughts appreciated. >> >> --fess >> >> >> >> >> >> ------------------------------------------------------- >> The SF.Net email is sponsored by EclipseCon 2004 >> Premiere Conference on Open Tools Development and Integration >> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >> http://www.eclipsecon.org/osdn >> _______________________________________________ >> Wigwam-devel mailing list >> Wig...@li... >> https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > -- |
From: Dave B. <da...@ff...> - 2004-02-05 00:15:36
|
i believe we want a package gettext-runtime which we can have by: configure_subdir=gettext-runtime configure_options=--disable-csharp anyways, that built for me... (only translators need the other parts of gettext, so let's omit them...) see the PACKAGING file in gettext for a few details... - dave On Wed, Feb 04, 2004 at 03:30:24PM -0800, fess wrote: > > > Hey, I've noticed that glib2 needs gettext to be installed: > > Finally, for message catalog handling, GTK+ requires an > implementation > of gettext(). If your system doesn't provide this functionality, > you should use the libintl library from the GNU gettext package, > > It turns out that (at least) the latest version of gnu gettext > requires, a c# compiler to compile it CIL hooks or something. > so, installing pnet, or mono as a dependancy of gettext, seems a little > excessive, does anyone have any ideas? > > > I was hoping glib2 could be compiled without gettext, but it doesn't > look like it. Also, I was hoping that possibly gettext could be > compiled > without the c# stuff, but there's not an obvious option. I might > be able to patch it, to do this. > > any thoughts appreciated. > > --fess > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel -- |
From: fess <fe...@ov...> - 2004-02-04 23:30:30
|
Hey, I've noticed that glib2 needs gettext to be installed: Finally, for message catalog handling, GTK+ requires an implementation of gettext(). If your system doesn't provide this functionality, you should use the libintl library from the GNU gettext package, It turns out that (at least) the latest version of gnu gettext requires, a c# compiler to compile it CIL hooks or something. so, installing pnet, or mono as a dependancy of gettext, seems a little excessive, does anyone have any ideas? I was hoping glib2 could be compiled without gettext, but it doesn't look like it. Also, I was hoping that possibly gettext could be compiled without the c# stuff, but there's not an obvious option. I might be able to patch it, to do this. any thoughts appreciated. --fess |
From: Tod E. K. <to...@ov...> - 2004-02-04 19:19:21
|
All the messy stuff that 'packagectl' does are nicely hidden, but occasionally it would be nice to have packagectl act verbose with what it is doing, without having to troll through log files post facto. Perhaps 'packagectl --verbose [action]' and/or 'packagectl -v -v [action]' for really verbose. Fess found me a workaround which is: WIGWAM_PROPELLER_MODE=stderr packagectl [action] but he suggested I send mail out to the general populace with the idea. -=tod |
From: fess <fe...@dd...> - 2004-02-04 01:08:35
|
On Feb 3, 2004, at 4:26 PM, Dave Benson wrote: > No, but i'm not sure where else i'd put it... > > Actually, looking at it a bit, i think there's > no technical reason at all to list .urls in > the .files and .md5sums files. if we didn't list it, > it might alleviate my chief concern, and it would > leave existing tools as is (like cheesy-upgrade and > rebuild-package-archive would still work) I agree, there are some packages that do not list the urls file in the md5sums file or the files file, so I'm all for that being the new best practice. and I'm in the "only the urls file should change camp" --fess |
From: Dave B. <da...@ff...> - 2004-02-04 00:26:58
|
No, but i'm not sure where else i'd put it... Actually, looking at it a bit, i think there's no technical reason at all to list .urls in the .files and .md5sums files. if we didn't list it, it might alleviate my chief concern, and it would leave existing tools as is (like cheesy-upgrade and rebuild-package-archive would still work) - dave On Tue, Feb 03, 2004 at 03:59:33PM -0800, Michael Radford wrote: > Is there any reason (backwards compatibility aside) the .urls file is > even in the package (as opposed to parallel to it, elsewhere in the > package archive)? > > Mike > > Dave Benson writes: > > hmm, that's a pretty interesting point... > > > > i've gotta say, i think making the .urls > > mutable like this seems reasonable, except > > that they happen to be included in the .md5sums > > file, which i've always thought of as a fingerprint > > of the package. > > > > since build-package-archive keeps a file cache > > by md5sum, if we just sorted by releases descending it > > would effectively cause later .urls files to have precedence. > > > > that being said, I dunno if it really makes any practical difference, > > so a policy workaround isn't too distasteful, especially > > since it's just stating existing practice... > > > > - dave > > > > > > On Tue, Feb 03, 2004 at 02:36:34PM -0800, Heather Sherman wrote: > > > > > > > Personally, I've always advocated a new package for any change... > > > > This isn't really a hard policy to live with, since 'cheesy-release' > > > > tends to do pretty well. > > > > > > Well, I don't think a new release should be created if the .urls is > > > updated (it sounds like you weren't excepting that one, Dave). > > > > > > The point of updating the .urls is to make the packagearchive build > > > nicely which won't happen if the old .urls file is left around in an > > > old release. This could lead to a case where the packagearchive could > > > not serve certain releases out to projects if the archive ever had to > > > be rebuilt from scratch. This is even less desirable than having > > > unexpected packages get added to a project. > > > > > > I'm in the "any other change should result in a new release" camp, > > > though. > > > > > > Heather > > > > > > > > > > > > ------------------------------------------------------- > > > The SF.Net email is sponsored by EclipseCon 2004 > > > Premiere Conference on Open Tools Development and Integration > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > http://www.eclipsecon.org/osdn > > > _______________________________________________ > > > Wigwam-devel mailing list > > > Wig...@li... > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > -- > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Wigwam-devel mailing list > > Wig...@li... > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel -- |
From: Michael R. <mr...@bl...> - 2004-02-03 23:59:35
|
Is there any reason (backwards compatibility aside) the .urls file is even in the package (as opposed to parallel to it, elsewhere in the package archive)? Mike Dave Benson writes: > hmm, that's a pretty interesting point... > > i've gotta say, i think making the .urls > mutable like this seems reasonable, except > that they happen to be included in the .md5sums > file, which i've always thought of as a fingerprint > of the package. > > since build-package-archive keeps a file cache > by md5sum, if we just sorted by releases descending it > would effectively cause later .urls files to have precedence. > > that being said, I dunno if it really makes any practical difference, > so a policy workaround isn't too distasteful, especially > since it's just stating existing practice... > > - dave > > > On Tue, Feb 03, 2004 at 02:36:34PM -0800, Heather Sherman wrote: > > > > > Personally, I've always advocated a new package for any change... > > > This isn't really a hard policy to live with, since 'cheesy-release' > > > tends to do pretty well. > > > > Well, I don't think a new release should be created if the .urls is > > updated (it sounds like you weren't excepting that one, Dave). > > > > The point of updating the .urls is to make the packagearchive build > > nicely which won't happen if the old .urls file is left around in an > > old release. This could lead to a case where the packagearchive could > > not serve certain releases out to projects if the archive ever had to > > be rebuilt from scratch. This is even less desirable than having > > unexpected packages get added to a project. > > > > I'm in the "any other change should result in a new release" camp, > > though. > > > > Heather > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Wigwam-devel mailing list > > Wig...@li... > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > -- > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel |
From: Dave B. <da...@ff...> - 2004-02-03 23:54:31
|
hmm, that's a pretty interesting point... i've gotta say, i think making the .urls mutable like this seems reasonable, except that they happen to be included in the .md5sums file, which i've always thought of as a fingerprint of the package. since build-package-archive keeps a file cache by md5sum, if we just sorted by releases descending it would effectively cause later .urls files to have precedence. that being said, I dunno if it really makes any practical difference, so a policy workaround isn't too distasteful, especially since it's just stating existing practice... - dave On Tue, Feb 03, 2004 at 02:36:34PM -0800, Heather Sherman wrote: > > > Personally, I've always advocated a new package for any change... > > This isn't really a hard policy to live with, since 'cheesy-release' > > tends to do pretty well. > > Well, I don't think a new release should be created if the .urls is > updated (it sounds like you weren't excepting that one, Dave). > > The point of updating the .urls is to make the packagearchive build > nicely which won't happen if the old .urls file is left around in an > old release. This could lead to a case where the packagearchive could > not serve certain releases out to projects if the archive ever had to > be rebuilt from scratch. This is even less desirable than having > unexpected packages get added to a project. > > I'm in the "any other change should result in a new release" camp, > though. > > Heather > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel -- |
From: Heather S. <he...@ce...> - 2004-02-03 22:37:32
|
> Personally, I've always advocated a new package for any change... > This isn't really a hard policy to live with, since 'cheesy-release' > tends to do pretty well. Well, I don't think a new release should be created if the .urls is updated (it sounds like you weren't excepting that one, Dave). The point of updating the .urls is to make the packagearchive build nicely which won't happen if the old .urls file is left around in an old release. This could lead to a case where the packagearchive could not serve certain releases out to projects if the archive ever had to be rebuilt from scratch. This is even less desirable than having unexpected packages get added to a project. I'm in the "any other change should result in a new release" camp, though. Heather |
From: Dave B. <da...@ff...> - 2004-02-03 21:00:21
|
Personally, I've always advocated a new package for any change... This isn't really a hard policy to live with, since 'cheesy-release' tends to do pretty well. However, without any enforcement, people inevitably get lazy and, to be fair, it doesn't really matter unless someone actually has installed that package. So, I'd prefer the hardline policy, but experience doesn't suggest we'll achieve it... - dave On Mon, Feb 02, 2004 at 12:14:05AM -0800, Christopher B. Liebman wrote: > I have to agree that it should *not* be ok to change the deps of a > package without bumping the revision/version. It could change the > installed set packages in an active project and potentially change the > projects behavior. Changing the urls file should be ok as long as the > tarball checksum is unchanged. > > -- Chris > > > > On Thu, 2004-01-29 at 11:15, fess wrote: > > I'lld like to say that it's been a policy all along to not change a > > package once it's been committed to the package archive, > > I'lld like to say that, but we've never quite stated that. Over time, > > it's become an obvious exception to this rule that > > .urls files can be updated without doing a new release of a package. ( > > the urls file is not used by any project, but by the package archive ) > > > > continuing work on this developing this "Policy" is it another > > exception that dep files can be updated? ( note nick > > adds a dep that was missing on a package, below. ) > > > > I think perhaps the answer is no, and that a new release should have > > been made for this change. > > > > thoughts? opinions? > > > > --fess > > > > > > > > Begin forwarded message: > > > > > From: Nick Conrad <nc...@us...> > > > Date: January 28, 2004 2:16:49 PM PST > > > To: wig...@li... > > > Subject: [Wigwam-archive-cvs] CVS: > > > wigwam-package-archive/public/perl-XML-LibXML-Common/0.13-1 > > > perl-XML-LibXML-Common-0.13-1.dep,1.1,1.2 > > > perl-XML-LibXML-Common-0.13-1.md5sums,1.1,1.2 > > > > > > Update of > > > /cvsroot/wigwam/wigwam-package-archive/public/perl-XML-LibXML-Common/ > > > 0.13-1 > > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13893 > > > > > > Modified Files: > > > perl-XML-LibXML-Common-0.13-1.dep > > > perl-XML-LibXML-Common-0.13-1.md5sums > > > Log Message: > > > this actually links against zlib > > > > > > Index: perl-XML-LibXML-Common-0.13-1.dep > > > =================================================================== > > > RCS file: > > > /cvsroot/wigwam/wigwam-package-archive/public/perl-XML-LibXML-Common/ > > > 0.13-1/perl-XML-LibXML-Common-0.13-1.dep,v > > > retrieving revision 1.1 > > > retrieving revision 1.2 > > > diff -u -r1.1 -r1.2 > > > --- perl-XML-LibXML-Common-0.13-1.dep 28 Jan 2004 21:29:25 -0000 1.1 > > > +++ perl-XML-LibXML-Common-0.13-1.dep 28 Jan 2004 22:16:46 -0000 1.2 > > > @@ -1 +1,2 @@ > > > libxml2 > > > +zlib > > > > > > Index: perl-XML-LibXML-Common-0.13-1.md5sums > > > =================================================================== > > > RCS file: > > > /cvsroot/wigwam/wigwam-package-archive/public/perl-XML-LibXML-Common/ > > > 0.13-1/perl-XML-LibXML-Common-0.13-1.md5sums,v > > > retrieving revision 1.1 > > > retrieving revision 1.2 > > > diff -u -r1.1 -r1.2 > > > --- perl-XML-LibXML-Common-0.13-1.md5sums 28 Jan 2004 21:29:27 > > > -0000 1.1 > > > +++ perl-XML-LibXML-Common-0.13-1.md5sums 28 Jan 2004 22:16:46 > > > -0000 1.2 > > > @@ -1,4 +1,4 @@ > > > -7e0fea8ae0ac4405e6c770117c3ca4fe perl-XML-LibXML-Common-0.13-1.dep > > > +e567019d79ea4423760fb6177f2109fe perl-XML-LibXML-Common-0.13-1.dep > > > bbb52ee386a3237b40a7231a2ba2bac8 perl-XML-LibXML-Common-0.13-1.files > > > 36200733524c27412d071bcc944734b7 perl-XML-LibXML-Common-0.13-1.options > > > 68b0b7498319fda4946f3654802e065d perl-XML-LibXML-Common-0.13-1.urls > > > > > > > > > > > > ------------------------------------------------------- > > > The SF.Net email is sponsored by EclipseCon 2004 > > > Premiere Conference on Open Tools Development and Integration > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > http://www.eclipsecon.org/osdn > > > _______________________________________________ > > > Wigwam-archive-cvs mailing list > > > Wig...@li... > > > https://lists.sourceforge.net/lists/listinfo/wigwam-archive-cvs > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Wigwam-devel mailing list > > Wig...@li... > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel -- |
From: Christopher B. L. <li...@zo...> - 2004-02-02 08:14:08
|
I have to agree that it should *not* be ok to change the deps of a package without bumping the revision/version. It could change the installed set packages in an active project and potentially change the projects behavior. Changing the urls file should be ok as long as the tarball checksum is unchanged. -- Chris On Thu, 2004-01-29 at 11:15, fess wrote: > I'lld like to say that it's been a policy all along to not change a > package once it's been committed to the package archive, > I'lld like to say that, but we've never quite stated that. Over time, > it's become an obvious exception to this rule that > .urls files can be updated without doing a new release of a package. ( > the urls file is not used by any project, but by the package archive ) > > continuing work on this developing this "Policy" is it another > exception that dep files can be updated? ( note nick > adds a dep that was missing on a package, below. ) > > I think perhaps the answer is no, and that a new release should have > been made for this change. > > thoughts? opinions? > > --fess > > > > Begin forwarded message: > > > From: Nick Conrad <nc...@us...> > > Date: January 28, 2004 2:16:49 PM PST > > To: wig...@li... > > Subject: [Wigwam-archive-cvs] CVS: > > wigwam-package-archive/public/perl-XML-LibXML-Common/0.13-1 > > perl-XML-LibXML-Common-0.13-1.dep,1.1,1.2 > > perl-XML-LibXML-Common-0.13-1.md5sums,1.1,1.2 > > > > Update of > > /cvsroot/wigwam/wigwam-package-archive/public/perl-XML-LibXML-Common/ > > 0.13-1 > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13893 > > > > Modified Files: > > perl-XML-LibXML-Common-0.13-1.dep > > perl-XML-LibXML-Common-0.13-1.md5sums > > Log Message: > > this actually links against zlib > > > > Index: perl-XML-LibXML-Common-0.13-1.dep > > =================================================================== > > RCS file: > > /cvsroot/wigwam/wigwam-package-archive/public/perl-XML-LibXML-Common/ > > 0.13-1/perl-XML-LibXML-Common-0.13-1.dep,v > > retrieving revision 1.1 > > retrieving revision 1.2 > > diff -u -r1.1 -r1.2 > > --- perl-XML-LibXML-Common-0.13-1.dep 28 Jan 2004 21:29:25 -0000 1.1 > > +++ perl-XML-LibXML-Common-0.13-1.dep 28 Jan 2004 22:16:46 -0000 1.2 > > @@ -1 +1,2 @@ > > libxml2 > > +zlib > > > > Index: perl-XML-LibXML-Common-0.13-1.md5sums > > =================================================================== > > RCS file: > > /cvsroot/wigwam/wigwam-package-archive/public/perl-XML-LibXML-Common/ > > 0.13-1/perl-XML-LibXML-Common-0.13-1.md5sums,v > > retrieving revision 1.1 > > retrieving revision 1.2 > > diff -u -r1.1 -r1.2 > > --- perl-XML-LibXML-Common-0.13-1.md5sums 28 Jan 2004 21:29:27 > > -0000 1.1 > > +++ perl-XML-LibXML-Common-0.13-1.md5sums 28 Jan 2004 22:16:46 > > -0000 1.2 > > @@ -1,4 +1,4 @@ > > -7e0fea8ae0ac4405e6c770117c3ca4fe perl-XML-LibXML-Common-0.13-1.dep > > +e567019d79ea4423760fb6177f2109fe perl-XML-LibXML-Common-0.13-1.dep > > bbb52ee386a3237b40a7231a2ba2bac8 perl-XML-LibXML-Common-0.13-1.files > > 36200733524c27412d071bcc944734b7 perl-XML-LibXML-Common-0.13-1.options > > 68b0b7498319fda4946f3654802e065d perl-XML-LibXML-Common-0.13-1.urls > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Wigwam-archive-cvs mailing list > > Wig...@li... > > https://lists.sourceforge.net/lists/listinfo/wigwam-archive-cvs > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel |
From: fess <fe...@dd...> - 2004-01-31 02:57:05
|
I'lld like to say that it's been a policy all along to not change a package once it's been committed to the package archive, I'lld like to say that, but we've never quite stated that. Over time, it's become an obvious exception to this rule that .urls files can be updated without doing a new release of a package. ( the urls file is not used by any project, but by the package archive ) continuing work on this developing this "Policy" is it another exception that dep files can be updated? ( note nick adds a dep that was missing on a package, below. ) I think perhaps the answer is no, and that a new release should have been made for this change. thoughts? opinions? --fess Begin forwarded message: > From: Nick Conrad <nc...@us...> > Date: January 28, 2004 2:16:49 PM PST > To: wig...@li... > Subject: [Wigwam-archive-cvs] CVS: > wigwam-package-archive/public/perl-XML-LibXML-Common/0.13-1 > perl-XML-LibXML-Common-0.13-1.dep,1.1,1.2 > perl-XML-LibXML-Common-0.13-1.md5sums,1.1,1.2 > > Update of > /cvsroot/wigwam/wigwam-package-archive/public/perl-XML-LibXML-Common/ > 0.13-1 > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13893 > > Modified Files: > perl-XML-LibXML-Common-0.13-1.dep > perl-XML-LibXML-Common-0.13-1.md5sums > Log Message: > this actually links against zlib > > Index: perl-XML-LibXML-Common-0.13-1.dep > =================================================================== > RCS file: > /cvsroot/wigwam/wigwam-package-archive/public/perl-XML-LibXML-Common/ > 0.13-1/perl-XML-LibXML-Common-0.13-1.dep,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -r1.1 -r1.2 > --- perl-XML-LibXML-Common-0.13-1.dep 28 Jan 2004 21:29:25 -0000 1.1 > +++ perl-XML-LibXML-Common-0.13-1.dep 28 Jan 2004 22:16:46 -0000 1.2 > @@ -1 +1,2 @@ > libxml2 > +zlib > > Index: perl-XML-LibXML-Common-0.13-1.md5sums > =================================================================== > RCS file: > /cvsroot/wigwam/wigwam-package-archive/public/perl-XML-LibXML-Common/ > 0.13-1/perl-XML-LibXML-Common-0.13-1.md5sums,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -r1.1 -r1.2 > --- perl-XML-LibXML-Common-0.13-1.md5sums 28 Jan 2004 21:29:27 > -0000 1.1 > +++ perl-XML-LibXML-Common-0.13-1.md5sums 28 Jan 2004 22:16:46 > -0000 1.2 > @@ -1,4 +1,4 @@ > -7e0fea8ae0ac4405e6c770117c3ca4fe perl-XML-LibXML-Common-0.13-1.dep > +e567019d79ea4423760fb6177f2109fe perl-XML-LibXML-Common-0.13-1.dep > bbb52ee386a3237b40a7231a2ba2bac8 perl-XML-LibXML-Common-0.13-1.files > 36200733524c27412d071bcc944734b7 perl-XML-LibXML-Common-0.13-1.options > 68b0b7498319fda4946f3654802e065d perl-XML-LibXML-Common-0.13-1.urls > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-archive-cvs mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-archive-cvs |
From: Dave B. <da...@ff...> - 2004-01-29 19:01:03
|
On Fri, Jan 23, 2004 at 09:22:26AM -0800, Paul Mineiro wrote: > On Fri, 23 Jan 2004, Dave Benson wrote: > > > > it's a question of how smart the maintainer mode is, wrt if a different > > > version of automake/autoconf is installed on the box than the one > > > "intended" to bootstrap the project. i don't know enough about that > > > magic "missing" script that automake uses ... but not enabling maintainer > > > mode seems safest in, e.g., a publish situation. > > > > > > so chris' suggestion of installing automake/autoconf into the project if > > > you're gonna regen configure seems appropriate. > > > > i think there's some confusion... by default, configure will > > include rebuild rules that don't require, but will use, the autotools. > > right, so, if there is _no_ automake/autoconf locally, "missing" does > the right thing. > > but what if there is one, with a version mismatch? sorry, i misread the original intention / got confused due to this terminology confusion: the effect of AM_MAINTAINER_MODE() is to *inhibit* maintainer mode, by default. - dave |
From: Paul M. <pmi...@he...> - 2004-01-29 08:38:45
|
On Fri, 23 Jan 2004, Dave Benson wrote: > > it's a question of how smart the maintainer mode is, wrt if a different > > version of automake/autoconf is installed on the box than the one > > "intended" to bootstrap the project. i don't know enough about that > > magic "missing" script that automake uses ... but not enabling maintainer > > mode seems safest in, e.g., a publish situation. > > > > so chris' suggestion of installing automake/autoconf into the project if > > you're gonna regen configure seems appropriate. > > i think there's some confusion... by default, configure will > include rebuild rules that don't require, but will use, the autotools. right, so, if there is _no_ automake/autoconf locally, "missing" does the right thing. but what if there is one, with a version mismatch? -- p |
From: Paul M. <pmi...@he...> - 2004-01-29 05:35:19
|
On Thu, 22 Jan 2004, Dave Benson wrote: > yep, i totally agree. ultimately the right thing is to > have a clear/obvious way that projectctl users can say whether they want > 'autogen.sh' etc run at 'projectctl configure' time. agreed. so, the wigwam4 way, which i did for wigwam4-base, servicectl, etc., was to put a (local) pre-build handler for the local package which runs the automake/autoconf stuff, and also a (local) dependency on automake and autoconf. this pre-build handler is generated with a .local from autogen.sh because when exporting the package, i don't want the hook in there (ditto for the dependency) ... but even for truly in-project code never meant to be exported, one would still want to optionally locally generate this hooks because at publish time we want to use whatever configure has been checked into CVS (hence not generate the hooks). one crappy part about this scheme is that automake and autoconf would be installed on the remote side during publish but not used, which is a little wasteful (yet another reason for role dynamic package lists). -- p I don't want to have to buy MS brand toilet paper one day to make my ass compatible. |
From: fess <fe...@dd...> - 2004-01-27 17:40:55
|
wigwam-base 3.1 was released, it includes many new features, and bug fixes. here are the relevant change log entries: wigwam-base (3.1) * bug fix: --force-checkout option to 'pubtool publish' now works. (fess) * all changes listed below from 3.0.49.1 - 3.0.49.12 -- john "fess" fessenden <fe...@dd...> Mon, 26 Jan 2004 09:43:53 -0800 wigwam-base (3.0.49.12) [3.1 candidate] * remove sgmltools check in wigwam-bootstrap not neccesary. (fess) * use "head -n 1" not "head -1" as newer version generate loud warnings. (liebman) * add --version option to wigwam-boostrap (fess) * make wigwam-bootstrap message a more clear when it "fails to connect" (fess) * repeated 'packagectl install's of packages that fail to build will now redownload package files. (fess) -- not publicly released (fess) Thu, 15 Jan 2004 21:28:08 -0800 wigwam-base (3.0.49.11) [beta] * bug-fix: wigwam-bootstrap was not resetting PLAYPEN_ROOT before sourcing setup-env; this made strange build errors with --initialize. * packagectl now has "info" mode (mrad) * bug-fix(3.0.49.4): wigwam-bootstrap was improperly checking for function support (daveb) * bug-fix(3.0.49.10): saved state of inital interactive shell vars fix for bash partially backed out, bash will require a future release. (fess) -- not publicly released (fess) Mon, 15 Dec 2003 21:03:26 -0800 wigwam-base (3.0.49.10) [beta] * service packages now copy .ping files into place properly. (maritatf) * bug-fix(3.0.49.4): load-config again makes PATH, LD_LIBRARY_PATH, and PERL5LIB eported to subshells of the load-config proccess. (molinaro/fess) * bug-fix(3.0.49.1): saved state of initial interactive shell vars works with bash now too. (fess) -- not publicly released, <fess> Mon, 24 Nov 2003 21:57:04 -0800 wigwam-base (3.0.49.9) [beta] * eval service_arguments in service start method * remove configure_options_eval, and simply eval configure_options, looked through all known instances of configure_options usage and this should not break things (molinaro/fess) * source the environment before building and before installing each package in order to allow packages to modify the environment for subsequent packages wigwam-base (3.0.49.8) [beta] * fix build-make-style to set configure_interpreter, which should only affect the case if the configure script is non-executable but configure_interpreter is not set. (daveb) * add variable $perl_makefile_options to build-make-style which packages can pass to subdirectories using ExtUtils::MakeMaker. (anthonym,daveb) * add configure_options_eval which will be evaluated by the shell as though its contents were entered literally on the 'configure' command-line. (anthonym,daveb) * undo the changes of 3.0.49.7 with respect to PERL5LIB. -- not publicly released wigwam-base (3.0.49.7) [beta] * add $PLAYPEN_ROOT/lib/perl5/site_perl, as well as $PLAYPEN_ROOT/ext/lib/perl5/site_perl to PERL5LIB * change the perl build make style to only take PREFIX, this will result in perl modules being mostly installed under the site_perl dirs, but removes lots of special cases -- not publicly released wigwam-base (3.0.49.6) [beta] * bugfix(intro 3.0.49.4) manpath checks are quiet, and not done on publish. as it was before. * add rtag option to pubtool -- not publicly released wigwam-base (3.0.49.5) [beta] * wigwam-boostrap now ignores comments in ext/package-archives (fess) * 3.0.49.4 broke unsetup-env. fixed. (molinaro/fess) * use-new-playpan / servicectl query-restart refactored. so publishing should be much faster. (fess) * publish now uses the new service filedeps rather than those from the previous publish. (fess) * load-config no longer sets CLASSPATH itself, wigwam does not need it set, and java developers rarely need what it was set to. (fess) -- not publicly released wigwam-base (3.0.49.4) [beta] * bugfix(introduced 3.0.49.1): protect special variables from being clobbered by users config scripts during load-config (molinaro/fess) * ww-env-diffs is now substituted with the correct path to perl * bugfix: packagectl uninstall will remove dirs in the installed files after removing all files first. (molinaro) * bugfix: load-config can now be sourced multiple times without any variables building on themselves. [as was intended in 3.0.49.1] (fess) * add an uninstall hook to packages, package-version.uninstall will be called at package-purge time. (lum/fess) -- not publicly released wigwam-base (3.0.49.3) [beta] * remove totally broken postponed-install code. (liebman) * remove exec from printf'd scripts in pubtool -- not portable (mineiro) * replace uwget.c with uwget (perl) which supports http_proxy for publishing to disconnected hosts (mineiro) * bugfix: a missing etc/role broke bootstrapping/autogen as of 3.0.49.1 now load-config tries it's best to continue (fess) * load-config exited on errors like a missing etc/role file are now just warnings. changes In 3.0.49.1 caused the old policies to fail to bootstrap when there was no role file (fess) -- not publicly released wigwam-base (3.0.49.2) [beta] * cleanup: start-service, stop-service, and restart-service are all deprecated by run-method in service_helpers (mineiro) * bugfix: wigwam-set-ppid used setenv() instead of the more portable putenv() (molinaro/fess) * bugfix: expand-sources wasn't expanding files correctly because guess-package-defaults got things wrong. (maritato) * bugfix: things echoed to standard out during load-config are mapped to stderr in all cases, not just make-setup-env (fess) * bugfix: 3.0.49.1 env changes broke publishing. fixed it. (fess) * wwmd5.c is made more portable. (mineiro) -- not publicly released wigwam-base (3.0.49.1) [beta] * fixed non-harmful messages from wigwam-bootstrap about -o command not found (liebman) * fixed order of awk search and removed export of AWK from wigwam-bootstrap (liebman) * introduced the wigwam env api [ext/bin/ww-env-api], a set of shell functions that can be used in load-config (fess) * bugfix: load-config/setup-env/make-setup-env can now be sourced multiple time without interactive variables building on themselves. (fess) * bugfix: sourcing ext/bin/unsetup-env now returns variables to their original state rather than just deleting them in some cases. (fess) * bugfix: changes during load-config to previously special variables such as PATH, CLASSPATH, LD_LIBRAY_PATH, ... are propagated to the interactive environment. (fess) * bugfix: things echoed to standard out during load-config are no longer sourced by callers to make-setup-env (fess) -- not publicly released |
From: Anthony M. <ant...@ov...> - 2004-01-27 01:55:04
|
That's pretty funny wigwam 4 does in fact deprecate projectctl and treats in project source code as a package (with dependencies, etc). This code is treated in exactly the same fashion as an installed package from an archive. A lot of the time I develop packages as a wigwam project which I just happen to export to an archive. Since by default wigwam 4 only provides packagectl (servicectl and pubtool are additional packages), you can have this sort of project managing a package very easily. I'm sure Paul will chime in if I missed any thing. So you may check out how wigwam 4 does it and possibly back port to wigwam 3. Hmm, it may not actually work since a lot of that stuff relys on the package uninstall which exists in wigwam 4. -Anthony On Thu, Jan 22, 2004 at 10:01:47PM -0800, Michael Radford wrote: > I see. Since the default has changed, the docs should really mention > that the only safe way to have automatic rebuilding is to install > autotools in the project. > > Checking in the configure script does seem safe and reasonable. > > Along that line, it also seems like there's such a short leap between > "project source code" and "a package in a local package archive whose > source happens to be in the project" that maybe wigwam4 should provide > tools to make the latter easy, so projectctl is no longer necessary, and > there can be stable releases of in-project libraries/services without > using branches. (Hmm, actually that won't be so hard...maybe I'll do it > that way under wigwam 3.) > > Mike > > Dave Benson writes: > > yep, i totally agree. ultimately the right thing is to > > have a clear/obvious way that projectctl users can say whether they want > > 'autogen.sh' etc run at 'projectctl configure' time. > > > > autoconf implementations have provided poor interface stability. > > so checking in 'configure' scripts, unpleasant as it is, > > is probably appropriate. > > > > so it seems that AM_MAINTAINER_MODE() is the most precise > > interface anywys, since the exact semantics are subtle. > > > > (additionally the default has changed (from false to true), so > > it's unstable terrain.) > > > > - dave > > > > > > On Thu, Jan 22, 2004 at 09:07:27PM -0800, Anthony Molinaro wrote: > > > Actually, I tend to prefer the use of AM_MAINTAINER_MODE because I > > > check configure scripts into CVS which will be run on many different > > > machines, many of which would fail to remake any of the > > > autoconf/automake because of extremely old versions of these. > > > > > > I guess one could avoid this by including autoconf/automake/etc > > > and dependencies. Anwyay, just mentioning this because it may > > > not always be a bad idea, just one that could cause problems if > > > used in the wrong way. > > > > > > -Anthony > > > > > > On Thu, Jan 22, 2004 at 05:25:33PM -0800, Michael Radford wrote: > > > > Ah, well of course, one way to avoid this problem is to not cut and > > > > paste AM_MAINTAINER_MODE into your configure.ac in the first place, so > > > > the automatic re-automake/autoconf rules are generated by default. :) > > > > > > > > So never mind.... Maybe I will add a note in the docs warning that > > > > AM_MAINTAINER_MODE is a bad idea in wigwam projects. > > > > > > > > Mike > > > > > > > > I wrote: > > > > > It seems that currently, when building project sources in > > > > > $PLAYPEN_ROOT/src, projectctl assumes that if a configure script is > > > > > present, it is up to date. (It only runs autogen.sh/bootstrap/whatever > > > > > if configure is not found.) > > > > > > > > > > Since we're operating out of cvs, however, this is a bad assumption. > > > > > When src/configure.ac is changed, we need to rerun autoconf. And > > > > > likewise for Makefile.am's and automake. > > > > > > > > > > One possible way to make this happen automatically for normal automake > > > > > projects is to pass --enable-maintainer-mode on the configure command > > > > > line (assuming we find AM_MAINTAINER_MODE in configure.ac, I guess). > > > > > > > > > > Any opinions on this, or better/more robust ways to handle it? Should > > > > > projectctl get smarter and start trying to compare file dates itself? > > > > > > > > > > Mike > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > > Premiere Conference on Open Tools Development and Integration > > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > > http://www.eclipsecon.org/osdn > > > > > _______________________________________________ > > > > > Wigwam-devel mailing list > > > > > Wig...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > > > > > > > > > ------------------------------------------------------- > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > Premiere Conference on Open Tools Development and Integration > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > http://www.eclipsecon.org/osdn > > > > _______________________________________________ > > > > Wigwam-devel mailing list > > > > Wig...@li... > > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > > > -- > > > ------------------------------------------------------------------------ > > > Anthony Molinaro <ant...@ov...> > > > > > > > > > ------------------------------------------------------- > > > The SF.Net email is sponsored by EclipseCon 2004 > > > Premiere Conference on Open Tools Development and Integration > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > http://www.eclipsecon.org/osdn > > > _______________________________________________ > > > Wigwam-devel mailing list > > > Wig...@li... > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > -- -- ------------------------------------------------------------------------ Anthony Molinaro <ant...@ov...> |
From: Michael R. <mr...@bl...> - 2004-01-23 19:24:10
|
Dave Benson writes: > If you plan on adding the autotools to your project > then I guess you can either omit AM_MAINTAINER_MODE() or include > project_configure_flags=--enable-maintainer-mode > (And this latter is actually the suggestion I prefer at the moment) Hmm, there doesn't seem to be a project_configure_flags (or project_configure_options, etc.) anywhere in wigwam-base. So looks like sourceforge cvs is down for the weekend...but when it's back up I will change that bit I added to the docs to reflect what we've discussed. Mike |
From: Anthony M. <ant...@ov...> - 2004-01-23 18:30:48
|
Sorry about the lateness of that message, still working out the kinks of using postfix on my laptop. -Anthony On Thu, Jan 22, 2004 at 11:10:53PM -0800, Anthony Molinaro wrote: > That's pretty funny wigwam 4 does in fact deprecate projectctl and > treats in project source code as a package (with dependencies, etc). > This code is treated in exactly the same fashion as an installed > package from an archive. A lot of the time I develop packages as > a wigwam project which I just happen to export to an archive. > > Since by default wigwam 4 only provides packagectl (servicectl and > pubtool are additional packages), you can have this sort of project > managing a package very easily. > > I'm sure Paul will chime in if I missed any thing. So you may > check out how wigwam 4 does it and possibly back port to wigwam 3. > Hmm, it may not actually work since a lot of that stuff relys on > the package uninstall which exists in wigwam 4. > > -Anthony > > On Thu, Jan 22, 2004 at 10:01:47PM -0800, Michael Radford wrote: > > I see. Since the default has changed, the docs should really mention > > that the only safe way to have automatic rebuilding is to install > > autotools in the project. > > > > Checking in the configure script does seem safe and reasonable. > > > > Along that line, it also seems like there's such a short leap between > > "project source code" and "a package in a local package archive whose > > source happens to be in the project" that maybe wigwam4 should provide > > tools to make the latter easy, so projectctl is no longer necessary, and > > there can be stable releases of in-project libraries/services without > > using branches. (Hmm, actually that won't be so hard...maybe I'll do it > > that way under wigwam 3.) > > > > Mike > > > > Dave Benson writes: > > > yep, i totally agree. ultimately the right thing is to > > > have a clear/obvious way that projectctl users can say whether they want > > > 'autogen.sh' etc run at 'projectctl configure' time. > > > > > > autoconf implementations have provided poor interface stability. > > > so checking in 'configure' scripts, unpleasant as it is, > > > is probably appropriate. > > > > > > so it seems that AM_MAINTAINER_MODE() is the most precise > > > interface anywys, since the exact semantics are subtle. > > > > > > (additionally the default has changed (from false to true), so > > > it's unstable terrain.) > > > > > > - dave > > > > > > > > > On Thu, Jan 22, 2004 at 09:07:27PM -0800, Anthony Molinaro wrote: > > > > Actually, I tend to prefer the use of AM_MAINTAINER_MODE because I > > > > check configure scripts into CVS which will be run on many different > > > > machines, many of which would fail to remake any of the > > > > autoconf/automake because of extremely old versions of these. > > > > > > > > I guess one could avoid this by including autoconf/automake/etc > > > > and dependencies. Anwyay, just mentioning this because it may > > > > not always be a bad idea, just one that could cause problems if > > > > used in the wrong way. > > > > > > > > -Anthony > > > > > > > > On Thu, Jan 22, 2004 at 05:25:33PM -0800, Michael Radford wrote: > > > > > Ah, well of course, one way to avoid this problem is to not cut and > > > > > paste AM_MAINTAINER_MODE into your configure.ac in the first place, so > > > > > the automatic re-automake/autoconf rules are generated by default. :) > > > > > > > > > > So never mind.... Maybe I will add a note in the docs warning that > > > > > AM_MAINTAINER_MODE is a bad idea in wigwam projects. > > > > > > > > > > Mike > > > > > > > > > > I wrote: > > > > > > It seems that currently, when building project sources in > > > > > > $PLAYPEN_ROOT/src, projectctl assumes that if a configure script is > > > > > > present, it is up to date. (It only runs autogen.sh/bootstrap/whatever > > > > > > if configure is not found.) > > > > > > > > > > > > Since we're operating out of cvs, however, this is a bad assumption. > > > > > > When src/configure.ac is changed, we need to rerun autoconf. And > > > > > > likewise for Makefile.am's and automake. > > > > > > > > > > > > One possible way to make this happen automatically for normal automake > > > > > > projects is to pass --enable-maintainer-mode on the configure command > > > > > > line (assuming we find AM_MAINTAINER_MODE in configure.ac, I guess). > > > > > > > > > > > > Any opinions on this, or better/more robust ways to handle it? Should > > > > > > projectctl get smarter and start trying to compare file dates itself? > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > > > Premiere Conference on Open Tools Development and Integration > > > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > > > http://www.eclipsecon.org/osdn > > > > > > _______________________________________________ > > > > > > Wigwam-devel mailing list > > > > > > Wig...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > > Premiere Conference on Open Tools Development and Integration > > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > > http://www.eclipsecon.org/osdn > > > > > _______________________________________________ > > > > > Wigwam-devel mailing list > > > > > Wig...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > > > > > -- > > > > ------------------------------------------------------------------------ > > > > Anthony Molinaro <ant...@ov...> > > > > > > > > > > > > ------------------------------------------------------- > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > Premiere Conference on Open Tools Development and Integration > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > http://www.eclipsecon.org/osdn > > > > _______________________________________________ > > > > Wigwam-devel mailing list > > > > Wig...@li... > > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > > > -- > > -- > ------------------------------------------------------------------------ > Anthony Molinaro <ant...@ov...> -- ------------------------------------------------------------------------ Anthony Molinaro <ant...@ov...> |
From: Dave B. <da...@ff...> - 2004-01-23 17:13:38
|
On Fri, Jan 23, 2004 at 08:43:13AM -0800, Paul Mineiro wrote: > On Thu, 22 Jan 2004, Michael Radford wrote: > > > Ah, well of course, one way to avoid this problem is to not cut and > > paste AM_MAINTAINER_MODE into your configure.ac in the first place, so > > the automatic re-automake/autoconf rules are generated by default. :) > > > > So never mind.... Maybe I will add a note in the docs warning that > > AM_MAINTAINER_MODE is a bad idea in wigwam projects. > > well, wait, i (might) disagree. > > it's a question of how smart the maintainer mode is, wrt if a different > version of automake/autoconf is installed on the box than the one > "intended" to bootstrap the project. i don't know enough about that > magic "missing" script that automake uses ... but not enabling maintainer > mode seems safest in, e.g., a publish situation. > > so chris' suggestion of installing automake/autoconf into the project if > you're gonna regen configure seems appropriate. i think there's some confusion... by default, configure will include rebuild rules that don't require, but will use, the autotools. AM_MAINTAINER_MODE() changes it to not use locally installed tools by default, but with manually specifying --enable-maintainer-mode then the tools become required. Therefore, use AM_MAINTAINER_MODE() if you plan on checking in configure. If you plan on adding the autotools to your project then I guess you can either omit AM_MAINTAINER_MODE() or include project_configure_flags=--enable-maintainer-mode (And this latter is actually the suggestion I prefer at the moment) - dave |
From: Paul M. <pmi...@he...> - 2004-01-23 16:56:30
|
On Thu, 22 Jan 2004, Michael Radford wrote: > Along that line, it also seems like there's such a short leap between > "project source code" and "a package in a local package archive whose > source happens to be in the project" that maybe wigwam4 should provide > tools to make the latter easy, so projectctl is no longer necessary, and > there can be stable releases of in-project libraries/services without > using branches. (Hmm, actually that won't be so hard...maybe I'll do it > that way under wigwam 3.) yes, there is no projectctl in ww4. all in-project source code is in package form. it happens to have a trivial download phase because the source code is already in place. check out README.Wigwam3 in wigwam4-base/src/wigwam-base-local for summary of changes from ww3. -- p |
From: Paul M. <pmi...@he...> - 2004-01-23 16:43:16
|
On Thu, 22 Jan 2004, Michael Radford wrote: > Ah, well of course, one way to avoid this problem is to not cut and > paste AM_MAINTAINER_MODE into your configure.ac in the first place, so > the automatic re-automake/autoconf rules are generated by default. :) > > So never mind.... Maybe I will add a note in the docs warning that > AM_MAINTAINER_MODE is a bad idea in wigwam projects. well, wait, i (might) disagree. it's a question of how smart the maintainer mode is, wrt if a different version of automake/autoconf is installed on the box than the one "intended" to bootstrap the project. i don't know enough about that magic "missing" script that automake uses ... but not enabling maintainer mode seems safest in, e.g., a publish situation. so chris' suggestion of installing automake/autoconf into the project if you're gonna regen configure seems appropriate. -- p |
From: Michael R. <mr...@bl...> - 2004-01-23 06:01:49
|
I see. Since the default has changed, the docs should really mention that the only safe way to have automatic rebuilding is to install autotools in the project. Checking in the configure script does seem safe and reasonable. Along that line, it also seems like there's such a short leap between "project source code" and "a package in a local package archive whose source happens to be in the project" that maybe wigwam4 should provide tools to make the latter easy, so projectctl is no longer necessary, and there can be stable releases of in-project libraries/services without using branches. (Hmm, actually that won't be so hard...maybe I'll do it that way under wigwam 3.) Mike Dave Benson writes: > yep, i totally agree. ultimately the right thing is to > have a clear/obvious way that projectctl users can say whether they want > 'autogen.sh' etc run at 'projectctl configure' time. > > autoconf implementations have provided poor interface stability. > so checking in 'configure' scripts, unpleasant as it is, > is probably appropriate. > > so it seems that AM_MAINTAINER_MODE() is the most precise > interface anywys, since the exact semantics are subtle. > > (additionally the default has changed (from false to true), so > it's unstable terrain.) > > - dave > > > On Thu, Jan 22, 2004 at 09:07:27PM -0800, Anthony Molinaro wrote: > > Actually, I tend to prefer the use of AM_MAINTAINER_MODE because I > > check configure scripts into CVS which will be run on many different > > machines, many of which would fail to remake any of the > > autoconf/automake because of extremely old versions of these. > > > > I guess one could avoid this by including autoconf/automake/etc > > and dependencies. Anwyay, just mentioning this because it may > > not always be a bad idea, just one that could cause problems if > > used in the wrong way. > > > > -Anthony > > > > On Thu, Jan 22, 2004 at 05:25:33PM -0800, Michael Radford wrote: > > > Ah, well of course, one way to avoid this problem is to not cut and > > > paste AM_MAINTAINER_MODE into your configure.ac in the first place, so > > > the automatic re-automake/autoconf rules are generated by default. :) > > > > > > So never mind.... Maybe I will add a note in the docs warning that > > > AM_MAINTAINER_MODE is a bad idea in wigwam projects. > > > > > > Mike > > > > > > I wrote: > > > > It seems that currently, when building project sources in > > > > $PLAYPEN_ROOT/src, projectctl assumes that if a configure script is > > > > present, it is up to date. (It only runs autogen.sh/bootstrap/whatever > > > > if configure is not found.) > > > > > > > > Since we're operating out of cvs, however, this is a bad assumption. > > > > When src/configure.ac is changed, we need to rerun autoconf. And > > > > likewise for Makefile.am's and automake. > > > > > > > > One possible way to make this happen automatically for normal automake > > > > projects is to pass --enable-maintainer-mode on the configure command > > > > line (assuming we find AM_MAINTAINER_MODE in configure.ac, I guess). > > > > > > > > Any opinions on this, or better/more robust ways to handle it? Should > > > > projectctl get smarter and start trying to compare file dates itself? > > > > > > > > Mike > > > > > > > > > > > > ------------------------------------------------------- > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > Premiere Conference on Open Tools Development and Integration > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > http://www.eclipsecon.org/osdn > > > > _______________________________________________ > > > > Wigwam-devel mailing list > > > > Wig...@li... > > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > > > > > > ------------------------------------------------------- > > > The SF.Net email is sponsored by EclipseCon 2004 > > > Premiere Conference on Open Tools Development and Integration > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > http://www.eclipsecon.org/osdn > > > _______________________________________________ > > > Wigwam-devel mailing list > > > Wig...@li... > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > -- > > ------------------------------------------------------------------------ > > Anthony Molinaro <ant...@ov...> > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Wigwam-devel mailing list > > Wig...@li... > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > -- |
From: Dave B. <da...@ff...> - 2004-01-23 05:36:59
|
yep, i totally agree. ultimately the right thing is to have a clear/obvious way that projectctl users can say whether they want 'autogen.sh' etc run at 'projectctl configure' time. autoconf implementations have provided poor interface stability. so checking in 'configure' scripts, unpleasant as it is, is probably appropriate. so it seems that AM_MAINTAINER_MODE() is the most precise interface anywys, since the exact semantics are subtle. (additionally the default has changed (from false to true), so it's unstable terrain.) - dave On Thu, Jan 22, 2004 at 09:07:27PM -0800, Anthony Molinaro wrote: > Actually, I tend to prefer the use of AM_MAINTAINER_MODE because I > check configure scripts into CVS which will be run on many different > machines, many of which would fail to remake any of the > autoconf/automake because of extremely old versions of these. > > I guess one could avoid this by including autoconf/automake/etc > and dependencies. Anwyay, just mentioning this because it may > not always be a bad idea, just one that could cause problems if > used in the wrong way. > > -Anthony > > On Thu, Jan 22, 2004 at 05:25:33PM -0800, Michael Radford wrote: > > Ah, well of course, one way to avoid this problem is to not cut and > > paste AM_MAINTAINER_MODE into your configure.ac in the first place, so > > the automatic re-automake/autoconf rules are generated by default. :) > > > > So never mind.... Maybe I will add a note in the docs warning that > > AM_MAINTAINER_MODE is a bad idea in wigwam projects. > > > > Mike > > > > I wrote: > > > It seems that currently, when building project sources in > > > $PLAYPEN_ROOT/src, projectctl assumes that if a configure script is > > > present, it is up to date. (It only runs autogen.sh/bootstrap/whatever > > > if configure is not found.) > > > > > > Since we're operating out of cvs, however, this is a bad assumption. > > > When src/configure.ac is changed, we need to rerun autoconf. And > > > likewise for Makefile.am's and automake. > > > > > > One possible way to make this happen automatically for normal automake > > > projects is to pass --enable-maintainer-mode on the configure command > > > line (assuming we find AM_MAINTAINER_MODE in configure.ac, I guess). > > > > > > Any opinions on this, or better/more robust ways to handle it? Should > > > projectctl get smarter and start trying to compare file dates itself? > > > > > > Mike > > > > > > > > > ------------------------------------------------------- > > > The SF.Net email is sponsored by EclipseCon 2004 > > > Premiere Conference on Open Tools Development and Integration > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > http://www.eclipsecon.org/osdn > > > _______________________________________________ > > > Wigwam-devel mailing list > > > Wig...@li... > > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Wigwam-devel mailing list > > Wig...@li... > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > -- > ------------------------------------------------------------------------ > Anthony Molinaro <ant...@ov...> > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel -- |
From: Anthony M. <ant...@ov...> - 2004-01-23 05:07:37
|
Actually, I tend to prefer the use of AM_MAINTAINER_MODE because I check configure scripts into CVS which will be run on many different machines, many of which would fail to remake any of the autoconf/automake because of extremely old versions of these. I guess one could avoid this by including autoconf/automake/etc and dependencies. Anwyay, just mentioning this because it may not always be a bad idea, just one that could cause problems if used in the wrong way. -Anthony On Thu, Jan 22, 2004 at 05:25:33PM -0800, Michael Radford wrote: > Ah, well of course, one way to avoid this problem is to not cut and > paste AM_MAINTAINER_MODE into your configure.ac in the first place, so > the automatic re-automake/autoconf rules are generated by default. :) > > So never mind.... Maybe I will add a note in the docs warning that > AM_MAINTAINER_MODE is a bad idea in wigwam projects. > > Mike > > I wrote: > > It seems that currently, when building project sources in > > $PLAYPEN_ROOT/src, projectctl assumes that if a configure script is > > present, it is up to date. (It only runs autogen.sh/bootstrap/whatever > > if configure is not found.) > > > > Since we're operating out of cvs, however, this is a bad assumption. > > When src/configure.ac is changed, we need to rerun autoconf. And > > likewise for Makefile.am's and automake. > > > > One possible way to make this happen automatically for normal automake > > projects is to pass --enable-maintainer-mode on the configure command > > line (assuming we find AM_MAINTAINER_MODE in configure.ac, I guess). > > > > Any opinions on this, or better/more robust ways to handle it? Should > > projectctl get smarter and start trying to compare file dates itself? > > > > Mike > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Wigwam-devel mailing list > > Wig...@li... > > https://lists.sourceforge.net/lists/listinfo/wigwam-devel > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Wigwam-devel mailing list > Wig...@li... > https://lists.sourceforge.net/lists/listinfo/wigwam-devel -- ------------------------------------------------------------------------ Anthony Molinaro <ant...@ov...> |