[83049] trunk/dports/lang/ecl/Portfile

Mark Evenson evenson at panix.com
Wed Aug 24 13:34:51 PDT 2011


On 8/24/11 10:23 PM, Ryan Schmidt wrote:
>
> It's not 11.1.1, but you're still installing it as if it were 11.1.1
> (by not changing the version field)? Yuck.

Agreed that it is suboptimal from a "when I install ecl-11.1.1 I expect 
that exact version point of view".  But currently there is *no* working 
ecl for Lion via MacPorts.   My intention is to remove the git fetch 
when a proper ecl release is cut, making this a transitory situation.

> If there are really so many changes from 11.1.1 that they could not
> be expressed as a patchfile, this really should have been a new
> ecl-devel port instead.

I wanted to get something out fast, rather than hunting through all the 
patches.  Creating an ecl-devel was the other option, but since this 
would ideally be a transient, one-time dependency, I opted to get the 
working port out there rather than having people hunt for ecl-devel.  If 
it turns out that this version of ECL under Lion is somehow bad, I 
promise to move to patches and/or ecl-devel.

My experience with xx-devel ports is that they "get stale".  They are 
used for a transient window, then the main trunk catches up to whatever 
caused the xx-devel version to be issued, and then the xx-devel lags. 
Can one remove a port and add it again later without issues?

> Why is setting CC, CXX, CPP only applicable here and not in the
> portfile generally?

ECL needs gcc-4.2 under Lion.  Setting configure.compiler wasn't enough: 
  the CC env. var. has to be passed to configure.  For other platforms, 
the default macports compilers are deemed to work.


-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."


More information about the macports-dev mailing list