Re: [ggt-devel] Building gmtl for MacPorts

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

Doug McCorkle wrote:
> On Jun 27, 2007, at 6:27 AM, Patrick Hartling wrote:
>=20
>> Doug McCorkle wrote:
>>> On Jun 26, 2007, at 8:17 PM, Doug McCorkle wrote:
>>>
>>>> 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 =20
>>>>>> relative
>>>>>> 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 =20
>>>>>>>> is the
>>>>>>>> prefix that is ultimately stored in the fpc file for the gmtl
>>>>>>>> installation prefix. It seems MacPorts expects another =20
>>>>>>>> command line
>>>>>>>> variable like stage_prefix or sandbox_prefix that allows the
>>>>>>>> installation to be staged but the location not written to =20
>>>>>>>> *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 =20
>>>>>>>> there
>>>>>>>> may be a better solution or adding the above mentioned prefix =20
>>>>>>>> and
>>>>>>>> associated target. What are everyones thoughts on this =20
>>>>>>>> subject? I
>>>>>>>> know there was a similar discussion on the cppdom list about =20
>>>>>>>> build
>>>>>>>> methods and steps which I am still working on for cppdom. I =20
>>>>>>>> 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 =20
>>>>>>> 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 =20
>>>> other
>>>> patch with sandbox_prefix.
>>>>
>>> This has a corrected versioned include path.
>> In what order are your patches to be applied?
>>
>=20
> There are two patches, only one should be applied. I implemented both  =

> for consideration based on what peoples preferences might be. Both =20
> solve the problem I mentioned originally.

I checked in the changes in the second version of the patch named
SConstruct.fpc.patch. I like that that one is a simple change that levera=
ges
the flexibility of Flagpoll.

 -Patrick


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