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." _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
