Can't access configure.env in portfile

[Ryan Schmidt]

On Jan 28, 2010, at 16:26, Dan Ports wrote:

> On Fri, Dec 11, 2009 at 04:12:30PM -0600, Ryan Schmidt wrote:
>> 
> 
>> On Dec 11, 2009, at 15:33, Rainer M?ller wrote:
>> 
>>> On 2009-11-29 15:33 , Ryan Schmidt wrote:
>>> 
>>>> See, both before and after the configure phase, configure.env only
>>>> contains the "FOO=bar" variable I added. But what I actually want to
>>>> know about are the CFLAGS, CPPFLAGS, CXXFLAGS, etc. that MacPorts
>>>> sets automatically. Yes, I know we have separate variables
>>>> ${configure.cflags}, ${configure.cppflags}, ${configure.cxxflags},
>>>> etc. for most (all?) of those, but I'd rather not have to enumerate
>>>> over them myself since to my mind MacPorts should have already done
>>>> so for me somewhere.
>>> 
>>> If you want to get better results for debugging use:
>>> configure.cmd /usr/bin/env
>> 
>> My reasons for asking were not for debugging but for a reworking of the php5extension portgroup. I've found out what I was doing wrong though and will be able to commit my update soon.
> 
> What solution did you wind up with? I'm wondering if it might be useful
> for a problem I'm having with the mit-scheme port where I also wanted
> to get ahold of configure.env:

You can see what I ended up doing by reading the php5extension portgroup.

I had been trying to use a technique I had first employed in the php5 port, in which, in order to build both an apache module and the fastcgi binary, it was necessary to run configure and make a second time. There, I have the port run "command_exec configure" and "command_exec build" directly in the destroot phase, after the port has already configured and built once. This is not recommended in ports because this is not part of the portfile vocabulary -- it's an internal MacPorts command that may change in the future (and indeed did already change once since I started making use of it in php5, breaking the port for awhile). I decided to use it anyway because I work on MacPorts daily and would be able to react quickly to fix the port if a change in base broke it.

For the php5extension portgroup, I noticed that running "command_exec" didn't set the environment variables. Trying to set them manually, I noticed that configure.env doesn't actually contain the default configure environment variables, which surprised me a little but that's just how it works. After looking through the muniversal portgroup and examining the base code for awhile, I instead went with portconfigure::configure_main, portconfigure::build_main and portconfigure::destroot_main, which do set the env variables first. These also probably shouldn't be used by a port for the same reasons as above. But portgroups used to be part of base, and other portgroups like muniversal already use these, so I felt ok about using them in this portgroup.

I don't think this will necessarily translate into something you should do for mit-scheme, but read on:


> The port needs to run configure/make more than once, as part of a
> bootstrapping process, so it skips configure and runs a (provided)
> shell script for the build phase. But then it doesn't get the
> configure environment -- currently the port build.env to have
> CC=${configure.cc}, but it's still missing out on CFLAGS and the rest,
> which is definitely a bug.
> 
> I wanted to deal with this basically by setting build.env =
> configure.env, but there's no obvious way to do that...

Yes, it may be simplest to just manually pass in all the relevant variables to build.env. Or, you could write your own configure script that does nothing but grab the environment and make it available to the build script. Attached is a diff that does this, but I haven't tested whether that helps the build in any way. (I wasn't sure what problem you were encountering by not having the environment variables set.)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mit-scheme-env.diff
Type: application/octet-stream
Size: 1531 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20100129/76057e56/attachment.obj>