[MacPorts] #21267: Changeset 56537 for openssl breaks macports 1.7.1

[MacPorts]

#21267: Changeset 56537 for openssl breaks macports 1.7.1
------------------------------+---------------------------------------------
  Reporter:  davilla@…        |       Owner:  macports-tickets@…                   
      Type:  defect           |      Status:  closed                               
  Priority:  Normal           |   Milestone:                                       
 Component:  ports            |     Version:  1.7.1                                
Resolution:  wontfix          |    Keywords:                                       
      Port:  openssl          |  
------------------------------+---------------------------------------------

Comment(by blb@…):

 Replying to [comment:5 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.

-- 
Ticket URL: <http://trac.macports.org/ticket/21267#comment:6>
MacPorts <http://www.macports.org/>
Ports system for Mac OS