1.5 rc1 tag created ([26762] tags/release_1_5_0-rc1/)
Evening everyone! I'm happy to announce that I'm almost done with the preparations for the 1.5 release, available time being the sole constraint, as always. I believe the release branch is almost ready to ship so I created a first and hopefully only release candidate tag in r26762 below, which we should all take for a test drive ;-) I will wait for two more things: 1) final word on http://trac.macports.org/projects/macports/ticket/ 12231, whether that's a final solution to the issue or just an advice to leave it out of the release for the time being; 2) final word on whether or not I should merge Anders' r26737. After that I'll start preparations for the final release, including creating the ports tree archive, the dmg installer, release announcement and whatever else is relevant, finally! In short, do speak up quick if you have anything to report ;-) Regards,... -jmpp Begin forwarded message:
From: source_changes@macosforge.org Date: July 6, 2007 1:16:29 AM GMT-04:00 To: macports-changes@lists.macosforge.org Subject: [26762] tags/release_1_5_0-rc1/ Reply-To: macports-dev@lists.macosforge.org
Revision 26762 Author jmpp@macports.org Date 2007-07-05 22:16:29 -0700 (Thu, 05 Jul 2007) Log Message Tagging a first and hopefully only release candidate of the 1.5 branch. Added Paths tags/release_1_5_0-rc1/ Diff Copied: tags/release_1_5_0-rc1 (from rev 26761, branches/release_1_5) _______________________________________________ macports-changes mailing list macports-changes@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-changes
Juan Manuel Palacios wrote:
I will wait for two more things:
1) final word on http://trac.macports.org/projects/macports/ticket/12231, whether that's a final solution to the issue or just an advice to leave it out of the release for the time being; 2) final word on whether or not I should merge Anders' r26737.
Main reason for #12231 is coping with selfupdate and ./configure. It works from the BSD port anyway, since that sets all arguments. If you're considering FreeBSD support, it should also be noted that configure currently assumes bash and the makefiles assumes gnumake... This means that "selfupdate" might not work out-of-the-box on systems where /bin/sh is some other shell and make is some other make (bsd) ? I think the very latest version of FreeBSD's sh is OK to use now (or one could edit configure to say /bin/bash), and using gmake instead of make will call FreeBSD's gnumake instead of bsdmake (the errors are due to GNU-make constructs like ifeq/ifneq...) If you want to address this portability problem, you can test with "./configure && bsdmake" - or you can just demand GNU make ? --anders
On Jul 6, 2007, at 3:20 PM, Anders F Björklund wrote:
Juan Manuel Palacios wrote:
I will wait for two more things:
1) final word on http://trac.macports.org/projects/macports/ticket/ 12231, whether that's a final solution to the issue or just an advice to leave it out of the release for the time being; 2) final word on whether or not I should merge Anders' r26737.
Main reason for #12231 is coping with selfupdate and ./configure. It works from the BSD port anyway, since that sets all arguments.
If you're considering FreeBSD support, it should also be noted that configure currently assumes bash and the makefiles assumes gnumake...
This means that "selfupdate" might not work out-of-the-box on systems where /bin/sh is some other shell and make is some other make (bsd) ?
I think the very latest version of FreeBSD's sh is OK to use now (or one could edit configure to say /bin/bash), and using gmake instead of make will call FreeBSD's gnumake instead of bsdmake (the errors are due to GNU-make constructs like ifeq/ifneq...)
If you want to address this portability problem, you can test with "./configure && bsdmake" - or you can just demand GNU make ?
The Makefiles used to be BSD make compatible. If configure && makefiles are incompatible with non-GNU tools, I'd consider that a bug.
Landon Fuller wrote:
If you're considering FreeBSD support, it should also be noted that configure currently assumes bash and the makefiles assumes gnumake...
The Makefiles used to be BSD make compatible. If configure && makefiles are incompatible with non-GNU tools, I'd consider that a bug.
Added it as: http://trac.macports.org/projects/macports/ticket/12247 Haven't verified that the MACOSX_DEPLOYMENT_TARGET works as intended, but the other two fixes should be OK - tested with "bsdmake" on Tiger. From what I recall the generated configure didn't work with the original FreeBSD 6.2 release version of /bin/sh, but did work after a portupgrade. If the 1.5.0 is going to be the *only* release in the "1.5 series" MacPorts, it would be great if it could be working out-of-the-box on FreeBSD 6.2 too ? But that'll also need the fixes for #12151, #12153, #12173, #12212, #12231... Then some of the ports need revisions, especially python24, icu and sqlite3 ? --anders
participants (3)
-
Anders F Björklund
-
Juan Manuel Palacios
-
Landon Fuller