|
From: Doug M. <mc...@ia...> - 2007-06-27 13:34:25
|
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?
Doug
|