Portfile for GEANT4

[Jann Röder]

One of my ports has the same problem,
I just use a ui_msg in post-activate to tell the user about this. Since
you don't know which shell a user is using (it's probably bash, but
still) it will be quite hard to do this automatically, not to mention
the trouble when upgrading or uninstalling the port.

Jann

Am 15.01.10 12:31, schrieb Cristiano Fontana:
> Thank you!
> Now I am trying for the n-th time to compile GEANT and see if the installation gets to the end.
> While I am waiting I will post another question.
> 
> Is there a way to set some environment variables that should be set at the beginning of any shell session?
> GEANT to work needs some variables to be set and provides a script that is supposed to be executed in the .porfile
> Do the uses has to put the script by hand in the .profile?
> 
> 	Cristiano
> 
> Il giorno 13/gen/2010, alle ore 22.43, Ryan Schmidt ha scritto:
> 
>>
>> On Jan 13, 2010, at 14:49, Joshua Root wrote:
>>
>>> On 2010-1-14 06:48 , Cristiano Fontana wrote:
>>>
>>>> What I am trying is to execute their configure script through port so I defined the following phases:
>>>>
>>>> build {
>>>>   catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -build -d -f ${worksrcpath}/config.sh" }
>>>> }
>>>>
>>>> destroot {
>>>>   catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -install" }
>>>> }
>>>
>>> You should use the 'system' procedure to run shell commands. Like so:
>>>
>>> build {
>>>   system "cd ${worksrcpath} && ./Configure -build -d -f config.sh"
>>> }
>>>
>>> destroot {
>>>   system "cd ${worksrcpath} && ./Configure -install" }
>>> }
>>>
>>> You could also achieve the same effect by setting build.cmd, build.args,
>>> build.target, etc. as needed, but this is so different to a standard
>>> autotools build that that is probably the messier route.
>>
>> Personally, I would highly recommend trying to use build.cmd, build.args, etc, instead of overriding the phases.
>>
>>
>