ggt-devel — Development discussion list

Re: [ggt-devel] Continue about the pygmtl problem.

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

I think that the problem is that the DLL manifest for gmtl.pyd is not being
found by the runtime loader. The PyGMTL build does not embed the manifest in
the DLL when using Visual C++ 8.0. This can be corrected. Build PyGMTL again
using the attached SConstruct file as a replacement for the one in your GMTL
source tree. (I assume that you are using GMTL 0.5.4.) You do not need to
clean your build tree if you still have it. The change I made only modifies
how gmtl.pyd is linked, so only the last step of the build needs to be
performed.

I don't know what the Unicode warning is about, but it seems like a Boost
problem. I don't see any non-ANSI characters in boost/utility/enable_if.hpp
after skimming it. It's too bad that the compiler does not say what line
contains the problematic character(s).

 -Patrick

Ming Jia wrote:
> Thank you for your detailed information.
> 
> I am sorry for sending you wrong information. As I checked my building
> steps again, I find the scon command will use the
> Using 'C:\Program
> Files\boost\boost_1_34_1\lib\boost_python-vc80-mt-1_34_1.dll'
> 
> Not the debug version of dll. And this dll can be found.
> So my problem is probably not the debug/release problem.
> 
> Also, is the unicode warning happened for other computers? it seems like
> a boost problem. But I do not know how to configure it.
> 
> Thanks.
> On 8/22/07, *Patrick Hartling* <pa...@13...
> <mailto:pa...@13...>> wrote:
> 
>     Ming Jia wrote:
>     > Sorry for opening a new thread of the same problem, I just subscribe
>     > this email list.
>     >
>     > I have set the path to boost-python in system path.
>     > That is set the C:\Program Files\boost\boost_1_34_0\lib  to %PATH%,
>     > and when using scons to build the pygmtl, the scons can find the
>     correct
>     > boost_python-vc80-mt-gd-1_34.dll  under this path.
>     >
>     > One thing that maybe helpful is that, when I use scons to build
>     pygmtl,
>     > I get the following warning for all the files.
>     >
>     > C:\Program Files\boost\boost_1_34_0\boost/utility/enable_if.hpp :
>     > warning C4819:
>     >  The file contains a character that cannot be represented in the
>     current
>     > code pa
>     > ge (936). Save the file in Unicode format to prevent data loss
>     >
>     >
>     > Is that related to my problem when issue "import gmtl" in python:
>     > Traceback (most recent call last):
>     >   File "<pyshell#0>", line 1, in <module>
>     >     import gmtl
>     > ImportError: DLL load failed: A dynamic link library (DLL)
>     > initialization routine failed.
>     >
>     > Another thing is that, right before the ImportError happens, there
>     is a
>     > window pop up, and saying:
>     >
>     > Runtime Error!
>     > Program: C:\Program Files\Python25\pythonw.exe
>     >
>     > R6034
>     > An application has made an attempt to load the C runtime library
>     > incorrectly.
>     >
>     > Thanks a lot for your help.
> 
>     It sounds as though you are mixing release and debug runtimes.
>     According to
>     your previous post, you built PyGMTL with optimization enabled, but
>     you are
>     now saying that it is linked against
>     boost_python-vc80-mt-gd-1_34.dll, which
>     is linked against the debug Visual C++ runtime. If you need to use
>     the debug
>     runtime, you need to have a version of python25.dll that is also linked
>     against the debug Visual C++ runtime (python25d.dll, IIRC).


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

Re: [ggt-devel] Continue about the pygmtl problem.

[Ming J. <ji...@gm...>]

Thank you for your detailed information.

I am sorry for sending you wrong information. As I checked my building steps
again, I find the scon command will use the
Using 'C:\Program
Files\boost\boost_1_34_1\lib\boost_python-vc80-mt-1_34_1.dll'

Not the debug version of dll. And this dll can be found.
So my problem is probably not the debug/release problem.

Also, is the unicode warning happened for other computers? it seems like a
boost problem. But I do not know how to configure it.

Thanks.
On 8/22/07, Patrick Hartling <pa...@13...> wrote:
>
> Ming Jia wrote:
> > Sorry for opening a new thread of the same problem, I just subscribe
> > this email list.
> >
> > I have set the path to boost-python in system path.
> > That is set the C:\Program Files\boost\boost_1_34_0\lib  to %PATH%,
> > and when using scons to build the pygmtl, the scons can find the correct
> > boost_python-vc80-mt-gd-1_34.dll  under this path.
> >
> > One thing that maybe helpful is that, when I use scons to build pygmtl,
> > I get the following warning for all the files.
> >
> > C:\Program Files\boost\boost_1_34_0\boost/utility/enable_if.hpp :
> > warning C4819:
> >  The file contains a character that cannot be represented in the current
> > code pa
> > ge (936). Save the file in Unicode format to prevent data loss
> >
> >
> > Is that related to my problem when issue "import gmtl" in python:
> > Traceback (most recent call last):
> >   File "<pyshell#0>", line 1, in <module>
> >     import gmtl
> > ImportError: DLL load failed: A dynamic link library (DLL)
> > initialization routine failed.
> >
> > Another thing is that, right before the ImportError happens, there is a
> > window pop up, and saying:
> >
> > Runtime Error!
> > Program: C:\Program Files\Python25\pythonw.exe
> >
> > R6034
> > An application has made an attempt to load the C runtime library
> > incorrectly.
> >
> > Thanks a lot for your help.
>
> It sounds as though you are mixing release and debug runtimes. According
> to
> your previous post, you built PyGMTL with optimization enabled, but you
> are
> now saying that it is linked against boost_python-vc80-mt-gd-1_34.dll,
> which
> is linked against the debug Visual C++ runtime. If you need to use the
> debug
> runtime, you need to have a version of python25.dll that is also linked
> against the debug Visual C++ runtime (python25d.dll, IIRC).
>
> -Patrick
>
>
> --
> Patrick L. Hartling
> VP Engineering, Infiscape Corp.
> http://www.infiscape.com/
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
>

Re: [ggt-devel] Continue about the pygmtl problem.

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

Ming Jia wrote:
> Sorry for opening a new thread of the same problem, I just subscribe
> this email list.
>=20
> I have set the path to boost-python in system path.
> That is set the C:\Program Files\boost\boost_1_34_0\lib  to %PATH%,
> and when using scons to build the pygmtl, the scons can find the correc=
t
> boost_python-vc80-mt-gd-1_34.dll  under this path.
>=20
> One thing that maybe helpful is that, when I use scons to build pygmtl,=

> I get the following warning for all the files.
>=20
> C:\Program Files\boost\boost_1_34_0\boost/utility/enable_if.hpp :
> warning C4819:
>  The file contains a character that cannot be represented in the curren=
t
> code pa
> ge (936). Save the file in Unicode format to prevent data loss
>=20
>=20
> Is that related to my problem when issue "import gmtl" in python:
> Traceback (most recent call last):
>   File "<pyshell#0>", line 1, in <module>
>     import gmtl
> ImportError: DLL load failed: A dynamic link library (DLL)
> initialization routine failed.
>=20
> Another thing is that, right before the ImportError happens, there is a=

> window pop up, and saying:
>=20
> Runtime Error!
> Program: C:\Program Files\Python25\pythonw.exe
>=20
> R6034
> An application has made an attempt to load the C runtime library
> incorrectly.
>=20
> Thanks a lot for your help.

It sounds as though you are mixing release and debug runtimes. According =
to
your previous post, you built PyGMTL with optimization enabled, but you a=
re
now saying that it is linked against boost_python-vc80-mt-gd-1_34.dll, wh=
ich
is linked against the debug Visual C++ runtime. If you need to use the de=
bug
runtime, you need to have a version of python25.dll that is also linked
against the debug Visual C++ runtime (python25d.dll, IIRC).

 -Patrick


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

[ggt-devel] Continue about the pygmtl problem.

[Ming J. <ji...@gm...>]

Sorry for opening a new thread of the same problem, I just subscribe this
email list.

I have set the path to boost-python in system path.
That is set the C:\Program Files\boost\boost_1_34_0\lib  to %PATH%,
and when using scons to build the pygmtl, the scons can find the correct
boost_python-vc80-mt-gd-1_34.dll  under this path.

One thing that maybe helpful is that, when I use scons to build pygmtl, I
get the following warning for all the files.

C:\Program Files\boost\boost_1_34_0\boost/utility/enable_if.hpp : warning
C4819:
 The file contains a character that cannot be represented in the current
code pa
ge (936). Save the file in Unicode format to prevent data loss


Is that related to my problem when issue "import gmtl" in python:
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    import gmtl
ImportError: DLL load failed: A dynamic link library (DLL) initialization
routine failed.

Another thing is that, right before the ImportError happens, there is a
window pop up, and saying:

Runtime Error!
Program: C:\Program Files\Python25\pythonw.exe

R6034
An application has made an attempt to load the C runtime library
incorrectly.

Thanks a lot for your help.

Re: [ggt-devel] a very basic problem of building pygmtl on windows

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

Ming Jia wrote:
> Hello all,
>=20
> I need to install the pygmtl on windows. However, after issuing the
> corresponding command of:
>=20
>        # cd <GMTL_HOME>
>        # scons optimize=3Dyes EnablePython=3DTrue \
>             BoostPythonDir=3D<BOOST_PYTHON
> _HOME> BoostVersion=3D<BOOST_VERSION>
>=20
> I get those things, and no *.pyc or *pyd is generated.
>=20
> 'tar' is not recognized as an internal or external command.
>=20
> Since I am on windows, what tar program do I need to install?

Ignore this. It is left over from a long time ago and should be removed f=
rom
the build.

> And for some methods, I happened to finished building the pygmtl, and
> get the gmtl.pyd, but when I issue:
> import gmtl in python, I get this error:
>>>> import gmtl
>=20
> Traceback (most recent call last):
>   File "<pyshell#6>", line 1, in <module>
>     import gmtl
> ImportError: DLL load failed: A dynamic link library (DLL)
> initialization routine failed.
>=20
> Did anyone happens to have the same problem before?

Do you have the Boost.Python DLL in your PATH environment variable settin=
g?

 -Patrick


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

[ggt-devel] a very basic problem of building pygmtl on windows

[Ming J. <ji...@gm...>]

Hello all,

I need to install the pygmtl on windows. However, after issuing the
corresponding command of:

       # cd <GMTL_HOME>
       # scons optimize=yes EnablePython=True \
            BoostPythonDir=<BOOST_PYTHON_HOME> BoostVersion=<BOOST_VERSION>

I get those things, and no *.pyc or *pyd is generated.

'tar' is not recognized as an internal or external command.

Since I am on windows, what tar program do I need to install?

And for some methods, I happened to finished building the pygmtl, and get
the gmtl.pyd, but when I issue:
import gmtl in python, I get this error:
>>> import gmtl

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in <module>
    import gmtl
ImportError: DLL load failed: A dynamic link library (DLL) initialization
routine failed.

Did anyone happens to have the same problem before?

Thanks.

[ggt-devel] OOBox and AABox functions

[Jared A. <jar...@gm...>]

I'm looking to do collision detection with an angled box.  It appears
collision detection is possible with an AABox but can not be rotated and
vice versa for the OOBox.  Is there some way to do collision detection with
the given functionality within gmtl?

-- 
Jared Abodeely
Iowa State University
Graduate Research Assistant
Virtual Engineering Research Group

office: (515)294-4979
cell:    (319)573-3270

[ggt-devel] GMTL 0.5.4 released

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

It's another day, and it's time for another GMTL release. This release
primarily targets improved (RPM) packaging. In particular, the following
items are of interest:

   * The gmtl-config script is now packaged separately from the GMTL
     headers so that gmtl-config, which is ostensibly deprecated, does
     not prevent the installation of multiple parallel versioned GMTL
     installations.
   * The GMTL API documentation is packaged in HTML and man page forms.
   * The packaging process has been improved by making the paths in the
     generated Flagpoll .fpc file relative so that the use of a staging
     root during packaging does not result in invalid paths appearing
     in the packaged files.

Bugs in the code for handling non-versioned installations on non-Windows
platforms have also been fixed.

The source code for this release can be downloaded here:

http://sourceforge.net/project/showfiles.php?group_id=3D43735&package_id=3D=
50702&release_id=3D519167

 -Patrick


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

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

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

Re: [ggt-devel] SConsAddons in gmtl and CppDOM

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

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

> Doug McCorkle wrote:
>> Hello,
>>        In gmtl and CppDOM it appears that they both utilize a variant
>> of SConsAddons. If that is true would it be possible to have both the
>> packages use SConsAddons rather than having their own variant of the
>> utility? Thanks.
>
> The GMTL build does not use SConsAddons. I believe that parts of  
> its build
> were used as the foundation for SConsAddons, however.
>
Ahh. I thought it was the other way around. Is there any desire to  
move it to SConsAddons?
> The CppDOM trunk now gets the current version of SConsAddons as an SVN
> external reference. The CppDOM 0.6 branch, OTOH, has an old version of
> SConsAddons and most likely does not build with the latest version.
>
I did not know this. Thanks for the update.

Doug

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/

Re: [ggt-devel] SConsAddons in gmtl and CppDOM

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

Doug McCorkle wrote:
> Hello,
>        In gmtl and CppDOM it appears that they both utilize a variant  =

> of SConsAddons. If that is true would it be possible to have both the  =

> packages use SConsAddons rather than having their own variant of the =20
> utility? Thanks.

The GMTL build does not use SConsAddons. I believe that parts of its buil=
d
were used as the foundation for SConsAddons, however.

The CppDOM trunk now gets the current version of SConsAddons as an SVN
external reference. The CppDOM 0.6 branch, OTOH, has an old version of
SConsAddons and most likely does not build with the latest version.

 -Patrick


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

[ggt-devel] SConsAddons in gmtl and CppDOM

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

Hello,
       In gmtl and CppDOM it appears that they both utilize a variant  
of SConsAddons. If that is true would it be possible to have both the  
packages use SConsAddons rather than having their own variant of the  
utility? Thanks.

Doug

Re: [ggt-devel] Building gmtl for MacPorts

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

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

Re: [ggt-devel] Building gmtl for MacPorts

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

Doug McCorkle wrote:
> On Jun 27, 2007, at 6:27 AM, Patrick Hartling wrote:
>=20
>> 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 =20
>>>>>> 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 =20
>>>>>>>> is the
>>>>>>>> prefix that is ultimately stored in the fpc file for the gmtl
>>>>>>>> installation prefix. It seems MacPorts expects another =20
>>>>>>>> command line
>>>>>>>> variable like stage_prefix or sandbox_prefix that allows the
>>>>>>>> installation to be staged but the location not written to =20
>>>>>>>> *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 =20
>>>>>>>> there
>>>>>>>> may be a better solution or adding the above mentioned prefix =20
>>>>>>>> and
>>>>>>>> associated target. What are everyones thoughts on this =20
>>>>>>>> subject? I
>>>>>>>> know there was a similar discussion on the cppdom list about =20
>>>>>>>> build
>>>>>>>> methods and steps which I am still working on for cppdom. I =20
>>>>>>>> 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 =20
>>>>>>> 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 =20
>>>> other
>>>> patch with sandbox_prefix.
>>>>
>>> This has a corrected versioned include path.
>> In what order are your patches to be applied?
>>
>=20
> There are two patches, only one should be applied. I implemented both  =

> for consideration based on what peoples preferences might be. Both =20
> 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 levera=
ges
the flexibility of Flagpoll.

 -Patrick


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

Re: [ggt-devel] Building gmtl for MacPorts

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

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.

Doug

Re: [ggt-devel] Building gmtl for MacPorts

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

Doug McCorkle wrote:
>=20
> On Jun 26, 2007, at 8:17 PM, Doug McCorkle wrote:
>=20
>>
>> 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 relati=
ve
>>>> 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 th=
e
>>>>>> prefix that is ultimately stored in the fpc file for the gmtl
>>>>>> installation prefix. It seems MacPorts expects another command lin=
e
>>>>>> 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.
>>
>=20
> This has a corrected versioned include path.

In what order are your patches to be applied?

 -Patrick


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

Re: [ggt-devel] Building gmtl for MacPorts

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

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.

Doug

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

Re: [ggt-devel] Building gmtl for MacPorts

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

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.

Doug

[ggt-devel] GMTL 0.5.3 released

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

A bug was found in the gmtl-config script in the 0.5.1 and 0.5.2 releases=
=2E
This release fixes the bug so that that script can be used if and when
Flagpoll is not available. The source can be downloaded from the followin=
g link:

https://sourceforge.net/project/showfiles.php?group_id=3D43735&package_id=
=3D50702&release_id=3D519032

 -Patrick


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

Re: [ggt-devel] Building gmtl for MacPorts

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

Doug McCorkle wrote:
> On Jun 26, 2007, at 11:40 AM, Patrick Hartling wrote:
>=20
>> 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 =20
>> fixing
>> it for CppDOM would allow a fix to be devised for GMTL--or vice =20
>> versa. It
>> would be good to get this issue resolved, but I don't know how to =20
>> fix it for
>> either case.
>=20
> Again, I am willing to create a potential patch for the issue but =20
> want to make sure the proposed method would be acceptable. Is an =20
> additional prefix target an acceptable solution? In general I like =20
> the way the gmtl build system works. With CppDOM I am running into =20
> 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:
>=20
> if sandbox_prefix and prefix are specified then install to =20
> sandbox_prefix and encode prefix
> if prefix is specified operate as normal
>=20
> Would this be an acceptable first cut at the problem?

That works for me.

 -Patrick


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

Re: [ggt-devel] Building gmtl for MacPorts

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

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

Re: [ggt-devel] Building gmtl for MacPorts

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

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?

Doug