Re: [ggt-devel] Building gmtl for MacPorts

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

On Jun 26, 2007, at 4:21 PM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> On Jun 26, 2007, at 11:40 AM, Patrick Hartling wrote:
>>
>>> 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.
>>> I don't know if a simpler solution is possible. One would hope that
>>> fixing
>>> it for CppDOM would allow a fix to be devised for GMTL--or vice
>>> versa. It
>>> would be good to get this issue resolved, but I don't know how to
>>> fix it for
>>> either case.
>>
>> Again, I am willing to create a potential patch for the issue but
>> want to make sure the proposed method would be acceptable. Is an
>> additional prefix target an acceptable solution? In general I like
>> the way the gmtl build system works. With CppDOM I am running into
>> general operation issues that cause problems so I cannot even address
>> this particular issue with CppDOM yet. So if the additional prefix is
>> acceptable the rule set surrounding may be something like:
>>
>> if sandbox_prefix and prefix are specified then install to
>> sandbox_prefix and encode prefix
>> if prefix is specified operate as normal
>>
>> Would this be an acceptable first cut at the problem?
>
> That works for me.

Here is the patch described above. In general I think there is a bug  
with the way the non-versioned headers build works.

Doug