Release 1.5 branch created

[Juan Manuel Palacios]

On Jul 4, 2007, at 5:23 PM, Anders F Björklund wrote:

> Landon Fuller wrote:
>
>>> http://trac.macports.org/projects/macports/ticket/12173
>> Outside of my immediate jurisdiction.
>
> It's just a failed test case or two anyway, not library code.


	Cc'd Kevin on the ticket so that he can take a look at this, while  
setting the ticket to "needs dev review" for easy tracking.

>
>>> http://trac.macports.org/projects/macports/ticket/12212
>> I -think- the right solution for this is to use -fconstant-string- 
>> class=NSConstantString for GNUstep. As a start, check out the  
>> OD_OBJC_NSCONSTANTSTRING macro I wrote here:
>>         http://svn.sourceforge.net/viewvc/substrate/trunk/ 
>> aclocal.m4?revision=283&view=markup
>
> Actually I just wanted MacPorts 1.5 to limp along and compile,
> as far as I know nothing is actually *using* tclobjc just yet
> and there was no test case for it to check whether it worked...


	Put this ticket also in "needs dev review".

>
>> http://trac.macports.org/projects/macports/ticket/12230
>>
>> I added a new pthread macro, committed to trunk.
>
> Was using "PTHREAD_LIBS=-lpthread ./configure" first, but
> that kinda broke any attempts to have it just selfupdate.
> Your macro is much better than either patch or workaround.
>
>>> http://trac.macports.org/projects/macports/ticket/12231
>>
>> Personally I'm in favor of just using --with-tcl-sqlite3, but I  
>> could be swayed either way.
>
> That would probably be much better, the idea was to provide
> enough of defaults so that "selfupdate" didn't choke and die...
> The initial BSD installation did provide an actual location.
>
> Another reason was that not providing a location for sqlite3
> means it will try and compile the included sqlite3 library,
> which seems even more hardcoded for Darwin than the path was.


	So fire up the autoconf foo and write up & commit the glue ;-)


>
>> I'll look into merging these changes into the 1.5 release branch,  
>> assuming nobody objects.
>
> I'm sure there will be lots of objections, as all patches were
> for making MacPorts "work" on FreeBSD which might be against
> the will of both several people and the project as a whole...
>
> My point was just that "we're not supporting FreeBSD anymore"
> doesn't *have* to mean "actively deleting everything freebsd" ?
> It was under my impression that it would still be tolerated.


	Totally tolerated in my opinion, as long as it doesn't hurt Mac OS X  
development and possibly leveraging platform specific technologies  
that simply wont work elsewhere... but I already made this point  
detailed enough in my previous post.

>
> But if we want to go ahead and wipe puredarwin/freebsd, OK.
> My main objective is testing RPM packaging anyway, and I have
> another option if MacPorts doesn't support FreeBSD anymore...
>
> --anders


	"Show me the packages!" ;-) Regards,....


-jmpp