Re: [ggt-devel] Building gmtl for MacPorts

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

On Jun 27, 2007, at 8:48 AM, Doug McCorkle wrote:

>
> 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....

This patch should do the trick.

Doug