[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