Re: [ggt-devel] Building gmtl for MacPorts

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

On Jun 27, 2007, at 8:45 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> On Jun 27, 2007, at 8:24 AM, Patrick Hartling wrote:
>>
>>> Doug McCorkle wrote:
>>>> 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.
>>> 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
>>> leverages
>>> the flexibility of Flagpoll.
>>
>> Thanks! Will this make its way to a release shortly or will release
>> be held off for a little bit?
>
> I hate to make a fourth release in only three days, but  
> fortunately, GMTL is
> relatively easy for people to update. It occurred to me yesterday  
> that our
> goal of being able to install multiple GMTL packages is being  
> prevented by
> the presence of gmtl-config, and I am going to separate that script  
> into its
> own package (gmtl-config-0.5.4-1.rpm, for example) so that one  
> version of
> the main gmtl package will not conflicct with another. I also want to
> include a package for the GMTL documentation, and that shouldn't be  
> hard to
> factor in.
>
> So, I guess the answer is that there will be a GMTL 0.5.4 release  
> shortly
> that focuses on better packaging and getting your patch out to users.
Before this occurs....

I just tested the non-versioned install and it does not work. Not  
sure why yet....

Doug