Re: [ggt-devel] Building gmtl for MacPorts

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

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.

Doug