Re: [ggt-devel] Building gmtl for MacPorts

[Doug M. <mc...@ia...>]

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  
>>> 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 is  
>>>>> the
>>>>> prefix that is ultimately stored in the fpc file for the gmtl
>>>>> installation prefix. It seems MacPorts expects another command  
>>>>> line
>>>>> 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.
>

This has a corrected versioned include path.

Doug