[108691] trunk/dports/www/serf1

[Ryan Schmidt]

On Aug 1, 2013, at 23:24, Blair Zajac wrote:

> On 8/1/13 9:15 PM, Jeremy Huddleston Sequoia wrote:
>> Please don't just drop +universal support from a port which provides libraries.
> 
> This wasn't intentional, I didn't know I was breaking it.  Looking through my commit again, there's nothing in there that indicated to me that it had universal support or it was going to break.

MacPorts has built-in support for universal variants for software using autotools. Certain directives disable it, including "use_configure no" since that implies that the software does not use autotools.

Some portgroups implement their own universal variants, for cases when the default is insufficient. These include the cmake, xcode and muniversal portgroups.

Individual portfiles may need to implement their own universal variants, if the provided defaults don't work for a particular software package.


>> Please be *EXTRA* careful not to break subversion, a dependent of serf which is now broken if +universal after this update.
>> 
>> It's a PITA when subversion breaks because many of us use subversion to update dports, so if you break subversion, it becomes non-trivial to update dports to get the fix.
> 
> Don't you get your primary architecture in any case?

You get the default build architecture of your compiler, or if the port properly supports build_arch, then you get that architecture.

> What happens if libserf-1.dylib has one of its architectures removed, does svn break?

I think svn should still continue to run, if you're running for an architecture of serf1 that still got built.

> I'm ignoring the fact in my question that libserf-1.0.dylib was renamed to libserf-1.dylib which required a rebuild.
> 
> Out of curiosity, why do people care about universal builds?  So they can rsync a build to another platform?  Just trying to understand the ramifications of this change.

Universal building is a feature MacPorts supports. I have it enabled by default on my system so that I can notice any problems with it and report those problems and get them fixed, hopefully before other users notice.

Users might want to use universal variants if they want to create redistributable packages of the software for use outside MacPorts.

Or, the user might not specifically want a universal build, but it is required because a port they do want to use is only available in a 32-bit version but they are on a computer which defaults to 64-bit builds. wine for example is in this group (though subversion is not in its rdeps).