Re: [ggt-devel] Building gmtl for MacPorts

[Patrick H. <pa...@13...>]

Doug McCorkle wrote:
>=20
> On Jun 26, 2007, at 8:17 PM, Doug McCorkle wrote:
>=20
>>
>> On Jun 26, 2007, at 4:08 PM, Doug McCorkle wrote:
>>
>>>
>>> On Jun 26, 2007, at 11:24 AM, Daniel E. Shipton wrote:
>>>
>>>> Look at the juggler fpc files.  There is a ${fp_cwd} variable (or
>>>> something close to it) that can you can set prefix with using relati=
ve
>>>> paths.
>>>>
>>> Right. It would be the simplest/quickest/cleanest solution but does
>>> not really address the problem in my opinion. If everyone is good
>>> with this option I will implement it this evening.
>>>
>>> Doug
>>>
>>>> -D
>>>>
>>>> On 6/26/07, Doug McCorkle <mc...@ia...> wrote:
>>>>>
>>>>> On Jun 26, 2007, at 11:01 AM, Doug McCorkle wrote:
>>>>>
>>>>>> Hello,
>>>>>>     I am trying to update the gmtl build in MacPorts with the
>>>>>> latest release but am running into problems with the build steps
>>>>>> required for MacPorts. MacPorts uses this scheme as noted here:
>>>>>>
>>>>>> http://trac.macosforge.org/projects/macports/wiki/BuildPhases
>>>>>>
>>>>>> When prefix is specified to install gmtl into destroot, that is th=
e
>>>>>> prefix that is ultimately stored in the fpc file for the gmtl
>>>>>> installation prefix. It seems MacPorts expects another command lin=
e
>>>>>> variable like stage_prefix or sandbox_prefix that allows the
>>>>>> installation to be staged but the location not written to *config,=

>>>>>> pc, and fpc files. I see where other packages employ scripts and
>>>>>> sed to overwrite these changes, which I can do, but it seems there=

>>>>>> may be a better solution or adding the above mentioned prefix and
>>>>>> associated target. What are everyones thoughts on this subject? I
>>>>>> know there was a similar discussion on the cppdom list about build=

>>>>>> methods and steps which I am still working on for cppdom. I hoping=

>>>>>> that a simpler solution can be arrived at here.
>>>>>>
>>>>>> Doug
>>>>>
>>>>> I forgot to mention that I was also thinking that a potential
>>>>> solution would be to use the flagpoll functionality that sets the
>>>>> prefix based on where the fpc file resides. This solution seems to =
be
>>>>> somewhat of a hack because the underlying build problem is still
>>>>> present but would solve the problem without many changes to the
>>>>> current build system.
>>>>>
>>>>> Doug
>>
>>
>> Attached is the patch described above. I am still working on the other=

>> patch with sandbox_prefix.
>>
>=20
> This has a corrected versioned include path.

In what order are your patches to be applied?

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/