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

[Ryan Schmidt]

On Aug 24, 2011, at 15:34, Mark Evenson wrote:

> 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.

Ok.


> 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.

In that light, I agree not creating ecl-devel was the right choice. But that's not always the case for -devel ports. Sometimes, the reason for creating the -devel port is to offer users a bleeding-edge option, especially for projects that don't release so often; if kept updated, this can be helpful. I try to keep most of my -devel ports up to date: libpixman, cairo, pango, glib2, graphviz, php5, wine, minivmac.


> Can one remove a port and add it again later without issues?

Yes that should be fine. Recently llvm-devel was reintroduced after having been gone (or at least "replaced_by llvm") for awhile.


>> 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.

MacPorts *does* pass the CC env var to configure for you, along with a bunch of other env vars, many influenced by what you set configure.compiler to. See the output of "sudo port -d configure".

If that is insufficient, then you can pass the env vars manually to the build phase, as you did in this revision for ecl. But it doesn't make sense that it should only need these flags on some platforms or with only some compilers. Either the build system needs this manual intervention always, or never.