Re: [ggt-devel] Building gmtl for MacPorts

[Patrick H. <pa...@13...>]

Doug McCorkle wrote:
> On Jun 27, 2007, at 8:24 AM, Patrick Hartling wrote:
>=20
>> 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 =20
>>>>>>>> (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 =20
>>>>>>> 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 =20
>>>>>>>>>> steps
>>>>>>>>>> required for MacPorts. MacPorts uses this scheme as noted =20
>>>>>>>>>> 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 =20
>>>>>>>>>> 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 =20
>>>>>>>>> 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 =20
>>>>>>>>> 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 =20
>> leverages
>> the flexibility of Flagpoll.
>=20
> Thanks! Will this make its way to a release shortly or will release =20
> 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 ou=
r
goal of being able to install multiple GMTL packages is being prevented b=
y
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.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/