Re: [ggt-devel] Building gmtl for MacPorts

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

On Jun 27, 2007, at 6:27 AM, Patrick Hartling wrote:

> 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  
>>>>> 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.
>
> In what order are your patches to be applied?
>

There are two patches, only one should be applied. I implemented both  
for consideration based on what peoples preferences might be. Both  
solve the problem I mentioned originally.

Doug