Changeset 56537 for openssl breaks macports 1.7.1

[davilla@…]

Changeset 56537 for openssl breaks macports 1.7.1 because "license" is not a keyword under MacPorts 1.7.1.

Please revert/fix so that 1.7.1 still works as this breaks the install/build for XBMC for Mac.

[blb@…]

Upgrading to MacPorts 1.8.0 will be the proper fix; going forward more of the additions in that version are going to be added to ports (eg, conflicts, replaced_by, license, etc).

[davilla@…]

Not possible, as you have taken away the ability to target previous SDKs with 1.8.0. In addition, many libs are hopelessly broke until upstream fixes them (libsdl for example) under 1.8.0 build on 10.6. We (TeamXBMC devs) build test and release on 10.4/10.5 and soon 10.6 and target a host of platforms ranging from older PPC, AppleTV to high end MacPros.

All we ask is that you not break existing portfiles. It's relatively easy to delimit these new additions. Otherwise what you propose is that all previous versions MacPorts will be abandoned as more an more portfiles are broken. As pointed out above, 1.8.0 is totally useless for building XBMC for Mac and neither XBMC devs, Boxee devs nor Plex devs can use it without major hacks. This issue hits the three major Media Center Apps and it's developers. This also effect the hundreds of users that build their own versions from our svn.

[blb@…]

For SDKs, that never worked quite right anyway due to platform variants; if you did get some things to work, that was pure luck.

As far as 10.6 support, you need 1.8.0 as 1.7.1 has issues there; not to mention the vast majority of issues there has to do with the default building of 64bit.

It may be easy to delimit in a few cases, but then such cases continue to grow, and grow, and grow. MacPorts definitely does not have anywhere near enough resources (people) to handle such a massive increase in workload.

[jmroot (Joshua Root)]

Fixing #19875 would be far less work than maintaining backwards compatibility in the portfiles in perpetuity.

[davilla@…]

I see excuses but no solutions offered. Targeting specific SDKs did work for us and our users. What you have done is fix the problem by removing the ability rather than solving the real problem. Apple's build system was engineered to be able to target specific SDK in order to maintain backward compatibility with previous OS versions. It works quite well. Xcode native builds in a sandbox, as could MacPorts.

As it stands, MacPorts WAS a very nice developer resource for building and deploying GPL applications that leveraged other GPL/LGPL libs on the Mac OS system. As it stands, under 1.8.0 a) we can not build, b) we can not deploy and c) our users can not build their own versions. Even existing MacPort 1.7.x installs will be broken if the dev/user does a selfupdate or a simple sync.

This problem also effects the two other XBMC forks, Boxee and Plex. So now three major OSX applications which have very broken builds. Looking over the tack tickets, we don't seem to be the only one affected.

We urge you to re-think this move and revert the ability to target SDKs.

[blb@…]

Replying to davilla@…:

I see excuses but no solutions offered.

This being an all-volunteer, open source project, patches are welcome.

Targeting specific SDKs did work for us and our users. What you have done is fix the problem by removing the ability rather than solving the real problem. Apple's build system was engineered to be able to target specific SDK in order to maintain backward compatibility with previous OS versions. It works quite well. Xcode native builds in a sandbox, as could MacPorts.

Building for a different version of the OS on which MacPorts is currently running has never been a supported option. The universal_sdk stuff was added in the early days of getting the universal variant stuff working. However, it was never actually needed for universal building, and was being abused, hence it was removed.

As it stands, MacPorts WAS a very nice developer resource for building and deploying GPL applications that leveraged other GPL/LGPL libs on the Mac OS system. As it stands, under 1.8.0 a) we can not build, b) we can not deploy and c) our users can not build their own versions. Even existing MacPort 1.7.x installs will be broken if the dev/user does a selfupdate or a simple sync.

As you say, Xcode does a great job of this kind of thing, and is definitely the tool you should be using for this. It would allow you to control the version of each dependency, how it is built, and how your final application links to them. MacPorts is definitely not the right tool for this particular task.

We urge you to re-think this move and revert the ability to target SDKs.

Again, if it worked, it was luck, plain and simple. Since Portfiles can specify how to build on a given OS version (but not how to target another version), some ports will not work with the SDK targetting. Also, with 10.6 building 64bit by default, this is going to be even more noticed if you try to build on 10.6 but want a build for a previous release.

If you really want to see MacPorts have the ability for both "how to build on version x.y.z" as well as another option for "how to build FOR version x.y.z", feel free to open a ticket for such an option.