Looking for a cure for weird scope/memory of variables
Mojca Miklavec
mojca at macports.org
Wed Jul 10 07:30:25 PDT 2013
Hi,
the more I read this thread, the more I find it all confusing.
Can someone suggest the best solution in case of this concrete example?
https://trac.macports.org/browser/users/mojca/ports/science/geant/Portfile
The variable ${geant.data_versions} works ok (but probably some nicer
code), but ${geant.datadir}, particularly inside destroot of
geant4-${geant.version}-data is problematic.
Thank you,
Mojca
On Wed, Jul 10, 2013 at 12:25 AM, Lawrence Velázquez wrote:
> On Jul 9, 2013, at 5:19 PM, Joshua Root wrote:
>
>> On 2013-7-10 03:56 , Clemens Lang wrote:
>>> On Tue, Jul 09, 2013 at 07:32:03PM +0200, Gustaf Neumann wrote:
>>>> foreach {foo.version foo.string} ${foo.versions} {
>>>> subport foo-${foo.version} [subst {
>>>> pre-fetch {
>>>> system "echo ${foo.version}"
>>>> }
>>>> fetch {}
>>>> extract {}
>>>> use_configure no
>>>> build {}
>>>> destroot {}
>>>> }]
>>>> }
>>>
>>> I assume there is no sane way to guess what the user wants and somehow
>>> integrate this into the subport (and pre-fetch, etc.) procs, is there?
>>>
>>> We could have a -subst switch, though:
>>> subport -subst {
>>> code
>>> }
>>
>> No need for that; using quotes instead of braces will achieve the same
>> thing. The trouble comes of course if you want to substitute some
>> variables at definition time and others at runtime (or at the top level
>> of the subport but not inside the pre-fetch or other internal
>> brace-wrapped string). I guess you could use 'format' on the body.
>
> For selective definition-time substitution, you could use string map (http://wiki.tcl.tk/37332#pagetoc04c6ab3f):
>
> foreach {foo.version foo.string} ${foo.versions} {
> set script {
> subport foo-${foo.version} {
> pre-fetch {
> system "echo ${foo.version}"
> }
> fetch {}
> extract {}
> use_configure no
> build {}
> destroot {}
> }
> }
> set script [string map [list \${foo.version} [list ${foo.version}]] $script]
> eval $script
> }
More information about the macports-dev
mailing list