On Mon, Mar 23, 2009 at 21:45, Marcus Calhoun-Lopez
wrote:
> Granted, but the extra functionality comes with a price, especially in
> Portfile creation and maintenance.
> It also adds the problem of dependencies.
> Now, if one port depends on another, then not only must they both be
> universal, t
Joshua Root writes:
> > Universal, however, should be limited to 32/64-bit universal as soon as
> > possible.
>
> I see no reason to limit the functionality. Changing the default archs,
> sure.
Granted, but the extra functionality comes with a price, especially in
Portfile creation and maintenan
On Mar 23, 2009, at 8:25 PM, Joshua Root wrote:
Bradley Giesbrecht wrote:
On Mar 23, 2009, at 3:50 PM, Anders F Björklund wrote:
[...]
We could also resume building RPMS, if someone wants to spend
some time on that. The build script could probably produce both
archives and packages in the sa
On Mar 23, 2009, at 22:25, Jeremy Huddleston wrote:
On Mar 23, 2009, at 18:43, Ryan Schmidt wrote:
Since rosetta doesn't handle ppc64, we can't narrow this down to
a single x86_64 box.
We can't narrow it down to a single Intel Mac per OS anyway
because one of the problems is that some sof
On Mar 23, 2009, at 18:43, Ryan Schmidt wrote:
Since rosetta doesn't handle ppc64, we can't narrow this down to a
single x86_64 box.
We can't narrow it down to a single Intel Mac per OS anyway because
one of the problems is that some software doesn't cross-compile
correctly. The point is
Bradley Giesbrecht wrote:
>
> On Mar 23, 2009, at 3:50 PM, Anders F Björklund wrote:
> [...]
>> We could also resume building RPMS, if someone wants to spend
>> some time on that. The build script could probably produce both
>> archives and packages in the same run, from the same destroot.
>
>
>
Marcus Calhoun-Lopez wrote:
> I am all for binary builds, but I would suggest that work on
> universal variants continue (personally I find them very useful).
It is useful to be able to build universal, but universal *variants* are
the wrong way of going about it.
> Universal, however, should be
On Mar 23, 2009, at 3:50 PM, Anders F Björklund wrote:
[...]
We could also resume building RPMS, if someone wants to spend
some time on that. The build script could probably produce both
archives and packages in the same run, from the same destroot.
RPM may be appealing to many for various re
On Mar 23, 2009, at 11:43, n...@macports.org wrote:
Revision: 48486
http://trac.macports.org/changeset/48486
Author: n...@macports.org
Date: 2009-03-23 09:43:17 -0700 (Mon, 23 Mar 2009)
Log Message:
---
libsdl: Enable nasm only on ppc (fix #18069).
Actually your change
Ryan Schmidt writes:
> I'm getting really burned out on universal.
...
>
> The new muniversal portgroup aims to solve this but has other severe
> problems, in that the configure phase runs once for each
> architecture, and some configure scripts are written wrong so they
> try to run a pro
On Mon, Mar 23, 2009 at 08:57:45PM -0500, Ryan Schmidt said:
>
> On Mar 23, 2009, at 09:49, Toby Peterson wrote:
>
>> On Mon, Mar 23, 2009 at 02:30, Ryan Schmidt wrote:
>>
>>> I was wondering if there might be a deprecation warning already. I
>>> don't
>>> think we should have a deprecation warni
On Mar 21, 2009, at 05:15, Joshua Root wrote:
Ryan Schmidt wrote:
On Mar 18, 2009, at 21:23, Jeremy Lavergne wrote:
When are we going to have the mass ports-upgrade to rid ourselves of
the default values that are going to be there (use_parallel_build
yes)? Is it going to be scripted or will
On Mar 23, 2009, at 09:49, Toby Peterson wrote:
On Mon, Mar 23, 2009 at 02:30, Ryan Schmidt wrote:
I was wondering if there might be a deprecation warning already. I
don't
think we should have a deprecation warning until after we've
released a
version of MacPorts including the new option
On Mar 23, 2009, at 16:04, C. Florian Ebeling wrote:
Is there a working example of migrating app data to a new format in a
some port? There are obviously a number of issues with doing something
like this:
- finding the source format version from a portfile with higher
version
- finding app da
On Mar 23, 2009, at 18:01, Jeremy Huddleston wrote:
On Mar 23, 2009, at 15:12, Ryan Schmidt wrote:
I would want (at least) one build server for each OS and processor
combination, but if we began with just a single Intel Leopard
machine, that would cover the majority of users. If we add a
On Mar 23, 2009, at 15:12, Ryan Schmidt wrote:
I would want (at least) one build server for each OS and processor
combination, but if we began with just a single Intel Leopard
machine, that would cover the majority of users. If we add a
corresponding PowerPC Leopard machine, then we could
Ryan Schmidt wrote:
Despite the fact that they cover much more than "just"
universal (arch) and configure (autotools), that is...
So it's more of a legacy quirk, than a design decision.
I'm getting really burned out on universal.
It sorta worked originally, but has probably outlived itself.
On Mar 23, 2009, at 05:47, Anders F Björklund wrote:
The +universal "variant" is a glorious mess that mixes all
of fatness (universalness, archness, whatever...) and
MDT and SDK together in one big undefined configuration.
Back then in the day, ppc+i386/10.4/MacOSX10.4u.sdk seemed
like a reason
Is there a working example of migrating app data to a new format in a
some port? There are obviously a number of issues with doing something
like this:
- finding the source format version from a portfile with higher version
- finding app data from a range of versions in possibly a number of locati
On Mon, Mar 23, 2009 at 02:30, Ryan Schmidt wrote:
> I was wondering if there might be a deprecation warning already. I don't
> think we should have a deprecation warning until after we've released a
> version of MacPorts including the new option name (so, after 1.8 is
> released).
It's deprecate
Toby Peterson wrote:
Ultimately the solution to this should be to simply stop building
against an SDK.
Nothing fundamentally wrong with building against an SDK, but it
shouldn't be tied to universal building, nor should it be the default
behavior.
The +universal "variant" is a glorious mess t
On Mar 22, 2009, at 02:31, Bryan Blackburn wrote:
On Sun, Mar 22, 2009 at 01:35:52AM -0500, Ryan Schmidt said:
On Mar 21, 2009, at 18:48, b...@macports.org wrote:
[...]
@@ -18,7 +18,12 @@
homepagehttp://irssi.org/
fetch.type svn
svn.url http://svn.irssi.or
Toby Peterson wrote:
On Sun, Mar 22, 2009 at 16:19, Ryan Schmidt
wrote:
So I ask again: can you think of any reason why we should not set
these
variables in the build, test and destroot phases? Can you think of
any
problems it would cause?
CC is probably safe, others not so much (e.g. C
Toby Peterson wrote:
> On Sun, Mar 22, 2009 at 16:19, Ryan Schmidt wrote:
>> So I ask again: can you think of any reason why we should not set these
>> variables in the build, test and destroot phases? Can you think of any
>> problems it would cause?
>
> CC is probably safe, others not so much (e
24 matches
Mail list logo
