ggt-devel — Development discussion list

[ggt-devel] for crossreferenc

[Amando C. <hol...@fa...>]

Hi,

VIArrGRA $3. 35
VALrrIUM $1. 25
CIArrLIS $3. 75
XArrNAX
SOrrMA

FOR LESS!

http://www.kedrx-com

Replace "-" with "." in the above link to make it working.



Cmon,  said Fred, grabbing Ginnys hand and starting to pull her
toward the wood. Harry, Ron, Hermione, and George followed. They all
looked back as they reached the trees. The crowd beneath the Roberts

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

[snip]

>
> Well, since no feedback has come yet, here's my plan:
>
>    1. Apply my changes to the build to clean up the escaping problem on
>       non-Windows platforms.
>    2. Drop pkg-config support in favor of Flagpoll.
>
> These changes would be made on the 0.4 branch to allow for a 0.4.13
> release
> and to the CVS HEAD branch to allow for a 0.5.1 release.
>
Sounds like a good plan to me.

> As for Windows and Flagpoll, I don't know whether Flagpoll works there,
> and
> until it does, I would prefer to not to have a GMTL release that depend=
s
> on
> Flagpoll. My expectation right now is that Flagpoll will be used from a
> DOS
> command shell on Windows, so that would leave gmtl-config for Cygwin
> purposes.
>
>

I agree. Again sounds like a good plan.

Doug

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

Patrick Hartling wrote:
> Doug McCorkle wrote:
>> On Feb 9, 2007, at 9:59 AM, Patrick Hartling wrote:
>>
>>> Doug McCorkle wrote:
>>>> On Feb 9, 2007, at 7:00 AM, Patrick Hartling wrote:
>>>>
>>>>> Doug McCorkle wrote:
>>>>>> [snip]
>>>>>>
>>>>>>>>>>> It certainly would be nice. I had always assumed that the =20
>>>>>>>>>>> SCons
>>>>>>>>>>> function
>>>>>>>>>>> PkgConfigBuilder() was injecting them, but I never tried =20
>>>>>>>>>>> tracking
>>>>>>>>>>> down their
>>>>>>>>>>> exact source.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> I will take a look and see if I can create a patch.
>>>>>>>>> How about this patch?
>>>>>>>> That's very interesting. I can see why re.escape() is being =20
>>>>>>>> used in
>>>>>>>> that
>>>>>>>> context, but I wonder if it's truly necessary. There is no
>>>>>>>> indication in the
>>>>>>>> revision history or in the code of a specific reason that =20
>>>>>>>> re.escape
>>>>>>>> () needs
>>>>>>>> to be used. It definitely is not needed for key given the
>>>>>>>> restrictions on
>>>>>>>> what key can be. For Windows, I can see where it would be =20
>>>>>>>> important to
>>>>>>>> ensure that the backslash characters in a path would be handled
>>>>>>>> properly,
>>>>>>>> but that's the only case I can think of. That can be handled mor=
e
>>>>>>>> directly
>>>>>>>> using str.replace().
>>>>>>>>
>>>>>>> Your comment about Windows makes sense. Please let me know if the=

>>>>>>> patch or a similar fix is committed. Thanks.
>>>>>> Any thoughts on this patch?
>>>>> Speaking only for myself, I'd rather see the escaping minimized =20
>>>>> on all
>>>>> platforms. I haven't had time to try any Windows-specific =20
>>>>> handling of the
>>>>> gmtl.pc generation on Windows, though. Currently, my thinking is =20
>>>>> that
>>>>> only
>>>>> backslashes and spaces should need to be escaped.
>>>>>
>>>> So would you like me to implement that or is this good enough for a
>>>> first cut? Currently we are working on getting flagpoll working on
>>>> windows so I have no real way to test pc and fpc files on windows =20
>>>> yet.
>>> I have come up with a patch that sort of works, but pkg-config is =20
>>> not being
>>> very friendly to me. It seems to dislike spaces in variable =20
>>> assignments. If
>>> I try to install GMTL to something under the directory C:\Program =20
>>> Files, it
>>> returns "-IC:\\Program\ " as the cflags value.
>>>
>>> Second, the character escape handling may needs to be different =20
>>> that I was
>>> originally thinking. From a command line, Visual C++ and GCC would =20
>>> accept an
>>> argument such as -I"C:\Program Files\GMTL 0.5.1\include" (with the =20
>>> quotes)
>>> from either a DOS shell or a Cygwin shell. However, I don't know =20
>>> what Visual
>>> C++ would make of -IC:\\Program\ Files\\GMTL\ 0.5.1\\include. I =20
>>> suspect that
>>> the DOS command shell will not deal with that correctly, but I haven'=
t
>>> tested it. A Cygwin shell would handle that case correctly as part =20
>>> of the
>>> command argument interpretation.
>>>
>>> Finally, quotes and escaped characters can get "lost in =20
>>> translation" as a
>>> value moves through repeated interpretation--at least in the case =20
>>> of UNIX
>>> shell-based builds relying on sh and make. Python and SCons =20
>>> probably bring
>>> some different behaviors to the table. For example, how will SCons (o=
r
>>> Python in general) deal with interpreting the output from running =20
>>> flagpoll
>>> for the above two paths? Will SCons do its own processing of the =20
>>> output to
>>> tokenize what it thinks are distinct arguments? If so, what are its
>>> expectations of token delineation? These sorts of problems are what  =

>>> tend to
>>> kill command line builds on Windows. Depending on the build tools =20
>>> in use,
>>> all too often you will find that they can work in a DOS shell or a =20
>>> Cygwin
>>> shell but rarely in both.
>>>
>>> My inclination would be to eschew Cygwin and concentrate on making =20
>>> a DOS
>>> command shell build work since that *should* allow it to be used =20
>>> from a
>>> Makefile-based project in Visual Studio using nmake. That would =20
>>> mean using
>>> quoting instead of escaping, which one would imagine to be an easier
>>> prospect. However, pkg-config doesn't seem to honor quoting within =20
>>> a .pc
>>> file, but I may not be using it correctly.
>>>
>>> Given that pkg-config has a lot of other problems besides the two =20
>>> things I
>>> have pointed out here and that it is probably meant to be run only =20
>>> from a
>>> Cygwin shell on Windows, it is probably not the correct tool for =20
>>> the job. If
>>> we were to target Flagpoll exclusively (at least for the Windows =20
>>> case), then
>>> we can ensure that Flagpoll behaves correctly WRT quoting and variabl=
e
>>> processing for .fpc files.
>>>
>>> Aside from all of that, I got gmtl-config to behave just as I =20
>>> wanted, but
>>> it's a simpler case because it is a standalone shell script. I =20
>>> suppose that
>>> this isn't too important as gmtl-config is probably considered =20
>>> deprecated.
>>> However, it might provide a better basis for a Cygwin shell build =20
>>> relying on
>>> GMTL than using pkg-config or flagpoll.
>> So that plan addresses quite a few shortfalls in the current code. It =
=20
>> seems there are quite a few issues to be address. Is there something  =

>> that I can do to help the testing/development process?
>=20
> I don't know. At this point, I need some feedback on how to proceed.
>=20
>> Will these =20
>> changes be propagated to cppdom as well?
>=20
> I don't know. That's not really up to me.
>=20
>> It seems that whatever the =20
>> outcome of this work is that it should be available in SConsAddons?
>=20
> I don't know. Again, that's not really up to me.

Well, since no feedback has come yet, here's my plan:

   1. Apply my changes to the build to clean up the escaping problem on
      non-Windows platforms.
   2. Drop pkg-config support in favor of Flagpoll.

These changes would be made on the 0.4 branch to allow for a 0.4.13 relea=
se
and to the CVS HEAD branch to allow for a 0.5.1 release.

As for Windows and Flagpoll, I don't know whether Flagpoll works there, a=
nd
until it does, I would prefer to not to have a GMTL release that depends =
on
Flagpoll. My expectation right now is that Flagpoll will be used from a D=
OS
command shell on Windows, so that would leave gmtl-config for Cygwin purp=
oses.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

Doug McCorkle wrote:
> On Feb 9, 2007, at 9:59 AM, Patrick Hartling wrote:
>=20
>> Doug McCorkle wrote:
>>> On Feb 9, 2007, at 7:00 AM, Patrick Hartling wrote:
>>>
>>>> Doug McCorkle wrote:
>>>>> [snip]
>>>>>
>>>>>>>>>> It certainly would be nice. I had always assumed that the =20
>>>>>>>>>> SCons
>>>>>>>>>> function
>>>>>>>>>> PkgConfigBuilder() was injecting them, but I never tried =20
>>>>>>>>>> tracking
>>>>>>>>>> down their
>>>>>>>>>> exact source.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I will take a look and see if I can create a patch.
>>>>>>>> How about this patch?
>>>>>>> That's very interesting. I can see why re.escape() is being =20
>>>>>>> used in
>>>>>>> that
>>>>>>> context, but I wonder if it's truly necessary. There is no
>>>>>>> indication in the
>>>>>>> revision history or in the code of a specific reason that =20
>>>>>>> re.escape
>>>>>>> () needs
>>>>>>> to be used. It definitely is not needed for key given the
>>>>>>> restrictions on
>>>>>>> what key can be. For Windows, I can see where it would be =20
>>>>>>> important to
>>>>>>> ensure that the backslash characters in a path would be handled
>>>>>>> properly,
>>>>>>> but that's the only case I can think of. That can be handled more=

>>>>>>> directly
>>>>>>> using str.replace().
>>>>>>>
>>>>>> Your comment about Windows makes sense. Please let me know if the
>>>>>> patch or a similar fix is committed. Thanks.
>>>>>
>>>>> Any thoughts on this patch?
>>>> Speaking only for myself, I'd rather see the escaping minimized =20
>>>> on all
>>>> platforms. I haven't had time to try any Windows-specific =20
>>>> handling of the
>>>> gmtl.pc generation on Windows, though. Currently, my thinking is =20
>>>> that
>>>> only
>>>> backslashes and spaces should need to be escaped.
>>>>
>>> So would you like me to implement that or is this good enough for a
>>> first cut? Currently we are working on getting flagpoll working on
>>> windows so I have no real way to test pc and fpc files on windows =20
>>> yet.
>> I have come up with a patch that sort of works, but pkg-config is =20
>> not being
>> very friendly to me. It seems to dislike spaces in variable =20
>> assignments. If
>> I try to install GMTL to something under the directory C:\Program =20
>> Files, it
>> returns "-IC:\\Program\ " as the cflags value.
>>
>> Second, the character escape handling may needs to be different =20
>> that I was
>> originally thinking. From a command line, Visual C++ and GCC would =20
>> accept an
>> argument such as -I"C:\Program Files\GMTL 0.5.1\include" (with the =20
>> quotes)
>> from either a DOS shell or a Cygwin shell. However, I don't know =20
>> what Visual
>> C++ would make of -IC:\\Program\ Files\\GMTL\ 0.5.1\\include. I =20
>> suspect that
>> the DOS command shell will not deal with that correctly, but I haven't=

>> tested it. A Cygwin shell would handle that case correctly as part =20
>> of the
>> command argument interpretation.
>>
>> Finally, quotes and escaped characters can get "lost in =20
>> translation" as a
>> value moves through repeated interpretation--at least in the case =20
>> of UNIX
>> shell-based builds relying on sh and make. Python and SCons =20
>> probably bring
>> some different behaviors to the table. For example, how will SCons (or=

>> Python in general) deal with interpreting the output from running =20
>> flagpoll
>> for the above two paths? Will SCons do its own processing of the =20
>> output to
>> tokenize what it thinks are distinct arguments? If so, what are its
>> expectations of token delineation? These sorts of problems are what =20
>> tend to
>> kill command line builds on Windows. Depending on the build tools =20
>> in use,
>> all too often you will find that they can work in a DOS shell or a =20
>> Cygwin
>> shell but rarely in both.
>>
>> My inclination would be to eschew Cygwin and concentrate on making =20
>> a DOS
>> command shell build work since that *should* allow it to be used =20
>> from a
>> Makefile-based project in Visual Studio using nmake. That would =20
>> mean using
>> quoting instead of escaping, which one would imagine to be an easier
>> prospect. However, pkg-config doesn't seem to honor quoting within =20
>> a .pc
>> file, but I may not be using it correctly.
>>
>> Given that pkg-config has a lot of other problems besides the two =20
>> things I
>> have pointed out here and that it is probably meant to be run only =20
>> from a
>> Cygwin shell on Windows, it is probably not the correct tool for =20
>> the job. If
>> we were to target Flagpoll exclusively (at least for the Windows =20
>> case), then
>> we can ensure that Flagpoll behaves correctly WRT quoting and variable=

>> processing for .fpc files.
>>
>> Aside from all of that, I got gmtl-config to behave just as I =20
>> wanted, but
>> it's a simpler case because it is a standalone shell script. I =20
>> suppose that
>> this isn't too important as gmtl-config is probably considered =20
>> deprecated.
>> However, it might provide a better basis for a Cygwin shell build =20
>> relying on
>> GMTL than using pkg-config or flagpoll.
>=20
> So that plan addresses quite a few shortfalls in the current code. It  =

> seems there are quite a few issues to be address. Is there something =20
> that I can do to help the testing/development process?

I don't know. At this point, I need some feedback on how to proceed.

> Will these =20
> changes be propagated to cppdom as well?

I don't know. That's not really up to me.

> It seems that whatever the =20
> outcome of this work is that it should be available in SConsAddons?

I don't know. Again, that's not really up to me.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

On Feb 9, 2007, at 9:59 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>>
>> On Feb 9, 2007, at 7:00 AM, Patrick Hartling wrote:
>>
>>> Doug McCorkle wrote:
>>>>>>>>>
>>>>
>>>> [snip]
>>>>
>>>>>>>>> It certainly would be nice. I had always assumed that the  
>>>>>>>>> SCons
>>>>>>>>> function
>>>>>>>>> PkgConfigBuilder() was injecting them, but I never tried  
>>>>>>>>> tracking
>>>>>>>>> down their
>>>>>>>>> exact source.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I will take a look and see if I can create a patch.
>>>>>>>
>>>>>>> How about this patch?
>>>>>>
>>>>>> That's very interesting. I can see why re.escape() is being  
>>>>>> used in
>>>>>> that
>>>>>> context, but I wonder if it's truly necessary. There is no
>>>>>> indication in the
>>>>>> revision history or in the code of a specific reason that  
>>>>>> re.escape
>>>>>> () needs
>>>>>> to be used. It definitely is not needed for key given the
>>>>>> restrictions on
>>>>>> what key can be. For Windows, I can see where it would be  
>>>>>> important to
>>>>>> ensure that the backslash characters in a path would be handled
>>>>>> properly,
>>>>>> but that's the only case I can think of. That can be handled more
>>>>>> directly
>>>>>> using str.replace().
>>>>>>
>>>>> Your comment about Windows makes sense. Please let me know if the
>>>>> patch or a similar fix is committed. Thanks.
>>>>
>>>>
>>>> Any thoughts on this patch?
>>>
>>> Speaking only for myself, I'd rather see the escaping minimized  
>>> on all
>>> platforms. I haven't had time to try any Windows-specific  
>>> handling of the
>>> gmtl.pc generation on Windows, though. Currently, my thinking is  
>>> that
>>> only
>>> backslashes and spaces should need to be escaped.
>>>
>> So would you like me to implement that or is this good enough for a
>> first cut? Currently we are working on getting flagpoll working on
>> windows so I have no real way to test pc and fpc files on windows  
>> yet.
>
> I have come up with a patch that sort of works, but pkg-config is  
> not being
> very friendly to me. It seems to dislike spaces in variable  
> assignments. If
> I try to install GMTL to something under the directory C:\Program  
> Files, it
> returns "-IC:\\Program\ " as the cflags value.
>
> Second, the character escape handling may needs to be different  
> that I was
> originally thinking. From a command line, Visual C++ and GCC would  
> accept an
> argument such as -I"C:\Program Files\GMTL 0.5.1\include" (with the  
> quotes)
> from either a DOS shell or a Cygwin shell. However, I don't know  
> what Visual
> C++ would make of -IC:\\Program\ Files\\GMTL\ 0.5.1\\include. I  
> suspect that
> the DOS command shell will not deal with that correctly, but I haven't
> tested it. A Cygwin shell would handle that case correctly as part  
> of the
> command argument interpretation.
>
> Finally, quotes and escaped characters can get "lost in  
> translation" as a
> value moves through repeated interpretation--at least in the case  
> of UNIX
> shell-based builds relying on sh and make. Python and SCons  
> probably bring
> some different behaviors to the table. For example, how will SCons (or
> Python in general) deal with interpreting the output from running  
> flagpoll
> for the above two paths? Will SCons do its own processing of the  
> output to
> tokenize what it thinks are distinct arguments? If so, what are its
> expectations of token delineation? These sorts of problems are what  
> tend to
> kill command line builds on Windows. Depending on the build tools  
> in use,
> all too often you will find that they can work in a DOS shell or a  
> Cygwin
> shell but rarely in both.
>
> My inclination would be to eschew Cygwin and concentrate on making  
> a DOS
> command shell build work since that *should* allow it to be used  
> from a
> Makefile-based project in Visual Studio using nmake. That would  
> mean using
> quoting instead of escaping, which one would imagine to be an easier
> prospect. However, pkg-config doesn't seem to honor quoting within  
> a .pc
> file, but I may not be using it correctly.
>
> Given that pkg-config has a lot of other problems besides the two  
> things I
> have pointed out here and that it is probably meant to be run only  
> from a
> Cygwin shell on Windows, it is probably not the correct tool for  
> the job. If
> we were to target Flagpoll exclusively (at least for the Windows  
> case), then
> we can ensure that Flagpoll behaves correctly WRT quoting and variable
> processing for .fpc files.
>
> Aside from all of that, I got gmtl-config to behave just as I  
> wanted, but
> it's a simpler case because it is a standalone shell script. I  
> suppose that
> this isn't too important as gmtl-config is probably considered  
> deprecated.
> However, it might provide a better basis for a Cygwin shell build  
> relying on
> GMTL than using pkg-config or flagpoll.

So that plan addresses quite a few shortfalls in the current code. It  
seems there are quite a few issues to be address. Is there something  
that I can do to help the testing/development process? Will these  
changes be propagated to cppdom as well? It seems that whatever the  
outcome of this work is that it should be available in SConsAddons?

Doug

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

Doug McCorkle wrote:
>=20
> On Feb 9, 2007, at 7:00 AM, Patrick Hartling wrote:
>=20
>> Doug McCorkle wrote:
>>>>>>>>
>>>
>>> [snip]
>>>
>>>>>>>> It certainly would be nice. I had always assumed that the SCons
>>>>>>>> function
>>>>>>>> PkgConfigBuilder() was injecting them, but I never tried trackin=
g
>>>>>>>> down their
>>>>>>>> exact source.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I will take a look and see if I can create a patch.
>>>>>>
>>>>>> How about this patch?
>>>>>
>>>>> That's very interesting. I can see why re.escape() is being used in=

>>>>> that
>>>>> context, but I wonder if it's truly necessary. There is no
>>>>> indication in the
>>>>> revision history or in the code of a specific reason that re.escape=

>>>>> () needs
>>>>> to be used. It definitely is not needed for key given the
>>>>> restrictions on
>>>>> what key can be. For Windows, I can see where it would be important=
 to
>>>>> ensure that the backslash characters in a path would be handled
>>>>> properly,
>>>>> but that's the only case I can think of. That can be handled more
>>>>> directly
>>>>> using str.replace().
>>>>>
>>>> Your comment about Windows makes sense. Please let me know if the
>>>> patch or a similar fix is committed. Thanks.
>>>
>>>
>>> Any thoughts on this patch?
>>
>> Speaking only for myself, I'd rather see the escaping minimized on all=

>> platforms. I haven't had time to try any Windows-specific handling of =
the
>> gmtl.pc generation on Windows, though. Currently, my thinking is that
>> only
>> backslashes and spaces should need to be escaped.
>>
> So would you like me to implement that or is this good enough for a
> first cut? Currently we are working on getting flagpoll working on
> windows so I have no real way to test pc and fpc files on windows yet.

I have come up with a patch that sort of works, but pkg-config is not bei=
ng
very friendly to me. It seems to dislike spaces in variable assignments. =
If
I try to install GMTL to something under the directory C:\Program Files, =
it
returns "-IC:\\Program\ " as the cflags value.

Second, the character escape handling may needs to be different that I wa=
s
originally thinking. From a command line, Visual C++ and GCC would accept=
 an
argument such as -I"C:\Program Files\GMTL 0.5.1\include" (with the quotes=
)
from either a DOS shell or a Cygwin shell. However, I don't know what Vis=
ual
C++ would make of -IC:\\Program\ Files\\GMTL\ 0.5.1\\include. I suspect t=
hat
the DOS command shell will not deal with that correctly, but I haven't
tested it. A Cygwin shell would handle that case correctly as part of the=

command argument interpretation.

Finally, quotes and escaped characters can get "lost in translation" as a=

value moves through repeated interpretation--at least in the case of UNIX=

shell-based builds relying on sh and make. Python and SCons probably brin=
g
some different behaviors to the table. For example, how will SCons (or
Python in general) deal with interpreting the output from running flagpol=
l
for the above two paths? Will SCons do its own processing of the output t=
o
tokenize what it thinks are distinct arguments? If so, what are its
expectations of token delineation? These sorts of problems are what tend =
to
kill command line builds on Windows. Depending on the build tools in use,=

all too often you will find that they can work in a DOS shell or a Cygwin=

shell but rarely in both.

My inclination would be to eschew Cygwin and concentrate on making a DOS
command shell build work since that *should* allow it to be used from a
Makefile-based project in Visual Studio using nmake. That would mean usin=
g
quoting instead of escaping, which one would imagine to be an easier
prospect. However, pkg-config doesn't seem to honor quoting within a .pc
file, but I may not be using it correctly.

Given that pkg-config has a lot of other problems besides the two things =
I
have pointed out here and that it is probably meant to be run only from a=

Cygwin shell on Windows, it is probably not the correct tool for the job.=
 If
we were to target Flagpoll exclusively (at least for the Windows case), t=
hen
we can ensure that Flagpoll behaves correctly WRT quoting and variable
processing for .fpc files.

Aside from all of that, I got gmtl-config to behave just as I wanted, but=

it's a simpler case because it is a standalone shell script. I suppose th=
at
this isn't too important as gmtl-config is probably considered deprecated=
=2E
However, it might provide a better basis for a Cygwin shell build relying=
 on
GMTL than using pkg-config or flagpoll.

 -Patrick

>> BTW, once this gets resolved, I think that GMTL 0.5.1 should be tagged=

>> for
>> release. I feel that it's important to get moving with the use of
>> versioned
>> GMTL installations.
>=20
> I agree. This will definitely make using versioned installs much easier=
=2E
>=20
> Doug


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

On Feb 9, 2007, at 7:00 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>>>>>>>
>>
>> [snip]
>>
>>>>>>> It certainly would be nice. I had always assumed that the SCons
>>>>>>> function
>>>>>>> PkgConfigBuilder() was injecting them, but I never tried  
>>>>>>> tracking
>>>>>>> down their
>>>>>>> exact source.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I will take a look and see if I can create a patch.
>>>>>
>>>>> How about this patch?
>>>>
>>>> That's very interesting. I can see why re.escape() is being used in
>>>> that
>>>> context, but I wonder if it's truly necessary. There is no
>>>> indication in the
>>>> revision history or in the code of a specific reason that re.escape
>>>> () needs
>>>> to be used. It definitely is not needed for key given the
>>>> restrictions on
>>>> what key can be. For Windows, I can see where it would be  
>>>> important to
>>>> ensure that the backslash characters in a path would be handled
>>>> properly,
>>>> but that's the only case I can think of. That can be handled more
>>>> directly
>>>> using str.replace().
>>>>
>>> Your comment about Windows makes sense. Please let me know if the
>>> patch or a similar fix is committed. Thanks.
>>
>>
>> Any thoughts on this patch?
>
> Speaking only for myself, I'd rather see the escaping minimized on all
> platforms. I haven't had time to try any Windows-specific handling  
> of the
> gmtl.pc generation on Windows, though. Currently, my thinking is  
> that only
> backslashes and spaces should need to be escaped.
>
So would you like me to implement that or is this good enough for a  
first cut? Currently we are working on getting flagpoll working on  
windows so I have no real way to test pc and fpc files on windows yet.

> BTW, once this gets resolved, I think that GMTL 0.5.1 should be  
> tagged for
> release. I feel that it's important to get moving with the use of  
> versioned
> GMTL installations.

I agree. This will definitely make using versioned installs much easier.

Doug

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

Doug McCorkle wrote:
>>>>>>
>=20
> [snip]
>=20
>>>>>> It certainly would be nice. I had always assumed that the SCons
>>>>>> function
>>>>>> PkgConfigBuilder() was injecting them, but I never tried tracking
>>>>>> down their
>>>>>> exact source.
>>>>>>
>>>>>>
>>>>>
>>>>> I will take a look and see if I can create a patch.
>>>>
>>>> How about this patch?
>>>
>>> That's very interesting. I can see why re.escape() is being used in
>>> that
>>> context, but I wonder if it's truly necessary. There is no
>>> indication in the
>>> revision history or in the code of a specific reason that re.escape
>>> () needs
>>> to be used. It definitely is not needed for key given the
>>> restrictions on
>>> what key can be. For Windows, I can see where it would be important t=
o
>>> ensure that the backslash characters in a path would be handled
>>> properly,
>>> but that's the only case I can think of. That can be handled more
>>> directly
>>> using str.replace().
>>>
>> Your comment about Windows makes sense. Please let me know if the
>> patch or a similar fix is committed. Thanks.
>=20
>=20
> Any thoughts on this patch?

Speaking only for myself, I'd rather see the escaping minimized on all
platforms. I haven't had time to try any Windows-specific handling of the=

gmtl.pc generation on Windows, though. Currently, my thinking is that onl=
y
backslashes and spaces should need to be escaped.

BTW, once this gets resolved, I think that GMTL 0.5.1 should be tagged fo=
r
release. I feel that it's important to get moving with the use of version=
ed
GMTL installations.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

>>>>>

[snip]

>>>>> It certainly would be nice. I had always assumed that the SCons
>>>>> function
>>>>> PkgConfigBuilder() was injecting them, but I never tried tracking
>>>>> down their
>>>>> exact source.
>>>>>
>>>>>
>>>>
>>>> I will take a look and see if I can create a patch.
>>>
>>> How about this patch?
>>
>> That's very interesting. I can see why re.escape() is being used in
>> that
>> context, but I wonder if it's truly necessary. There is no
>> indication in the
>> revision history or in the code of a specific reason that re.escape
>> () needs
>> to be used. It definitely is not needed for key given the
>> restrictions on
>> what key can be. For Windows, I can see where it would be  
>> important to
>> ensure that the backslash characters in a path would be handled
>> properly,
>> but that's the only case I can think of. That can be handled more
>> directly
>> using str.replace().
>>
> Your comment about Windows makes sense. Please let me know if the
> patch or a similar fix is committed. Thanks.


Any thoughts on this patch?

Doug

Re: [ggt-devel] RlidX

[Jo S. <st...@sa...>]

Hi,

Vivagra  3. 35
Ciavlis  3. 75
Valvium  1. 25
Sovma    1. 15
Ambvien  2. 90

http://www.zonr*x.com

Important: Remove "*" in the above link



help her down the golden steps.
Madame Maxime closed the door behind her, Hagrid offered her his arm,
and they set off around the edge of the paddock containing Madame

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

On Feb 5, 2007, at 8:43 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>>
>> On Feb 4, 2007, at 12:43 PM, Doug McCorkle wrote:
>>
>>>
>>> On Feb 4, 2007, at 8:02 AM, Patrick Hartling wrote:
>>>
>>>> Doug McCorkle wrote:
>>>>> On Jan 3, 2007, at 7:32 PM, Daniel E. Shipton wrote:
>>>>>
>>>>>> This may be that scons doesn't handle the escape characters that
>>>>>> are in the gmtl.pc file.  Those extra escape character probably
>>>>>> don't need to be there but maybe there was a reason...?
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>>
>>>>> [snip]
>>>>>
>>>>> Was there a resolution to the need for the escape characters in  
>>>>> the
>>>>> pc file? It would be nice if they could be removed.
>>>>
>>>> It certainly would be nice. I had always assumed that the SCons  
>>>> function
>>>> PkgConfigBuilder() was injecting them, but I never tried tracking
>>>> down their
>>>> exact source.
>>>>
>>>>
>>>
>>> I will take a look and see if I can create a patch.
>>
>> How about this patch?
>
> That's very interesting. I can see why re.escape() is being used in  
> that
> context, but I wonder if it's truly necessary. There is no  
> indication in the
> revision history or in the code of a specific reason that re.escape 
> () needs
> to be used. It definitely is not needed for key given the  
> restrictions on
> what key can be. For Windows, I can see where it would be important to
> ensure that the backslash characters in a path would be handled  
> properly,
> but that's the only case I can think of. That can be handled more  
> directly
> using str.replace().
>
Your comment about Windows makes sense. Please let me know if the  
patch or a similar fix is committed. Thanks.

Doug

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

Doug McCorkle wrote:
>=20
> On Feb 4, 2007, at 12:43 PM, Doug McCorkle wrote:
>=20
>>
>> On Feb 4, 2007, at 8:02 AM, Patrick Hartling wrote:
>>
>>> Doug McCorkle wrote:
>>>> On Jan 3, 2007, at 7:32 PM, Daniel E. Shipton wrote:
>>>>
>>>>> This may be that scons doesn't handle the escape characters that
>>>>> are in the gmtl.pc file.  Those extra escape character probably
>>>>> don't need to be there but maybe there was a reason...?
>>>>>
>>>>> -Dan
>>>>>
>>>>
>>>> [snip]
>>>>
>>>> Was there a resolution to the need for the escape characters in the
>>>> pc file? It would be nice if they could be removed.
>>>
>>> It certainly would be nice. I had always assumed that the SCons funct=
ion
>>> PkgConfigBuilder() was injecting them, but I never tried tracking
>>> down their
>>> exact source.
>>>
>>>
>>
>> I will take a look and see if I can create a patch.
>=20
> How about this patch?

That's very interesting. I can see why re.escape() is being used in that
context, but I wonder if it's truly necessary. There is no indication in =
the
revision history or in the code of a specific reason that re.escape() nee=
ds
to be used. It definitely is not needed for key given the restrictions on=

what key can be. For Windows, I can see where it would be important to
ensure that the backslash characters in a path would be handled properly,=

but that's the only case I can think of. That can be handled more directl=
y
using str.replace().

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

On Feb 4, 2007, at 12:43 PM, Doug McCorkle wrote:

>
> On Feb 4, 2007, at 8:02 AM, Patrick Hartling wrote:
>
>> Doug McCorkle wrote:
>>> On Jan 3, 2007, at 7:32 PM, Daniel E. Shipton wrote:
>>>
>>>> This may be that scons doesn't handle the escape characters that
>>>> are in the gmtl.pc file.  Those extra escape character probably
>>>> don't need to be there but maybe there was a reason...?
>>>>
>>>> -Dan
>>>>
>>>
>>> [snip]
>>>
>>> Was there a resolution to the need for the escape characters in the
>>> pc file? It would be nice if they could be removed.
>>
>> It certainly would be nice. I had always assumed that the SCons  
>> function
>> PkgConfigBuilder() was injecting them, but I never tried tracking  
>> down their
>> exact source.
>>
>>
>
> I will take a look and see if I can create a patch.

How about this patch?

Doug

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

On Feb 4, 2007, at 8:02 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> On Jan 3, 2007, at 7:32 PM, Daniel E. Shipton wrote:
>>
>>> This may be that scons doesn't handle the escape characters that
>>> are in the gmtl.pc file.  Those extra escape character probably
>>> don't need to be there but maybe there was a reason...?
>>>
>>> -Dan
>>>
>>
>> [snip]
>>
>> Was there a resolution to the need for the escape characters in the
>> pc file? It would be nice if they could be removed.
>
> It certainly would be nice. I had always assumed that the SCons  
> function
> PkgConfigBuilder() was injecting them, but I never tried tracking  
> down their
> exact source.
>
>

I will take a look and see if I can create a patch.

Doug

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

Doug McCorkle wrote:
> On Jan 3, 2007, at 7:32 PM, Daniel E. Shipton wrote:
>=20
>> This may be that scons doesn't handle the escape characters that =20
>> are in the gmtl.pc file.  Those extra escape character probably =20
>> don't need to be there but maybe there was a reason...?
>>
>> -Dan
>>
>=20
> [snip]
>=20
> Was there a resolution to the need for the escape characters in the =20
> pc file? It would be nice if they could be removed.

It certainly would be nice. I had always assumed that the SCons function
PkgConfigBuilder() was injecting them, but I never tried tracking down th=
eir
exact source.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

On Jan 3, 2007, at 7:32 PM, Daniel E. Shipton wrote:

> This may be that scons doesn't handle the escape characters that  
> are in the gmtl.pc file.  Those extra escape character probably  
> don't need to be there but maybe there was a reason...?
>
> -Dan
>

[snip]

Was there a resolution to the need for the escape characters in the  
pc file? It would be nice if they could be removed.

Doug

Re: [ggt-devel] new PHAsumRMA

[Carbry C. <si...@wb...>]

Hi,

Get your meds from our site because it costs much less.

http://www.zo*nrx.com

Remove "*" to make the link working!

--

Probably mistaken the day. I daresay their kind dont set much store by
punctuality. Either that or they drive some tin-pot car thats broken
dAAAAAAAARRRRRGH! 

Re: [ggt-devel] my EDoffwhit

[Evstathios L. <afi...@na...>]

Good day,

VlAG_GRA  $1, 80
ClAL_LIS  $3, 00
LEVl_ITRA $3, 35

http://www.rabietichb*com
( Important! Replace * with . )

--
Its upstairs,  said Harry, grinning back.
Well get it,  said Fred at once. Winking at Harry, he and George left
the room. They knew where Harrys bedroom was, having once rescued him

Re: [ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

On Jan 3, 2007, at 2:22 PM, Doug McCorkle wrote:

> Hello,
>      I am having an odd problem with the pc file generated with the  
> gmtl 0.4.12 build when running on RHEL 4. When I run flagpoll  
> within scons such as:
>
> flagpoll vrjuggler --get-vrj-ogl-libs --libs --cflags
>
> I get a mangled include path for gmtl:
>
> -I. -I/home/vr/Applications/TSVEG/Libraries/Release/Opt/VTK-5.0/ 
> Linux-RHEL4/include/vtk-5.0 -I/home/vr/Applications/TSVEG/Libraries/ 
> Release/Opt/OSG-1.2/Linux-RHEL_4/include -I/usr/include -I/home/vr/ 
> Applications/TSVEG/Libraries/Release/Opt/Boost-1.33.1/Linux-RHEL4/ 
> include/boost-1_33_1 -I/home/vr/Applications/TSVEG/Libraries/ 
> Release/Opt/ACE-TAO-5.5/Linux-RHEL_4/include -I/home/users/sgent/ 
> TSVEG/ACE_TAO/ACE_TAO_5_5_0/Linux-RHEL_4/include -I/usr/X11R6/ 
> include -I/home/vr/Applications/TSVEG/Libraries/Release/Opt/ 
> VRJuggler-2.0.1-branch/Linux-RHEL4/include -I/home/vr/Applications/ 
> TSVEG/Libraries/Release/Opt/cppdom-0.6.6/Linux-RHEL4/include - 
> Ibuild.linux.2.0-redhat-4.i686.ia32/VE_Xplorer/GE/\/home\/vr\/ 
> Applications\/TSVEG\/Libraries\/Release\/Opt\/GMTL\-0\.4\.12\/Linux 
> \-RHEL4\/include -IVE_Xplorer/GE/\/home\/vr\/Applications\/TSVEG\/ 
> Libraries\/Release\/Opt\/GMTL\-0\.4\.12\/Linux\-RHEL4\/include
>
> Please note the last line with the gmtl include path. The pc file  
> has the correct path but when scons parses the output from flagpoll  
> it appears to butcher the gmtl include path. If I remove the \ from  
> the include path in the gmtl pc file everything works fine. Is this  
> an issue that can be resolved by changing the formating in the pc  
> file or should this be addressed by scons? Also, I do not see this  
> problem on my mac.
>
> On the RHEL 4 machine:
>
> |keymaker|~/svn_VE_Suite/VE_Suite> scons --version
> SCons by Steven Knight et al.:
>         script: v0.96.93.D001, 2006/11/06 08:31:54, by knight on  
> roxbury
>         engine: v0.96.93.D001, 2006/11/06 08:31:54, by knight on  
> roxbury
> Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation
> |keymaker|~/svn_VE_Suite/VE_Suite>
>
> On my mac:
>
> objects:~ mccdo$ scons --version
> SCons by Steven Knight et al.:
>         script: v0.96.92.D002, 2006/04/11 07:39:43, by knight on  
> roxbury
>         engine: v0.96.92.D002, 2006/04/11 07:39:43, by knight on  
> roxbury
> Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation
> objects:~ mccdo$
>
> Thanks for the help.
>


I did some more checking and the problem appears on my mac as well.  
The build is just not affected due to the way things are installed.  
So it appears to be a general scons parsing error as flagpoll when  
run on the command line displays to correct include path.

Doug

[ggt-devel] Problems with the new pc files with 0.4.12 on RHEL 4 and scons 0.96.93

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

Hello,
      I am having an odd problem with the pc file generated with the  
gmtl 0.4.12 build when running on RHEL 4. When I run flagpoll within  
scons such as:

flagpoll vrjuggler --get-vrj-ogl-libs --libs --cflags

I get a mangled include path for gmtl:

-I. -I/home/vr/Applications/TSVEG/Libraries/Release/Opt/VTK-5.0/Linux- 
RHEL4/include/vtk-5.0 -I/home/vr/Applications/TSVEG/Libraries/Release/ 
Opt/OSG-1.2/Linux-RHEL_4/include -I/usr/include -I/home/vr/ 
Applications/TSVEG/Libraries/Release/Opt/Boost-1.33.1/Linux-RHEL4/ 
include/boost-1_33_1 -I/home/vr/Applications/TSVEG/Libraries/Release/ 
Opt/ACE-TAO-5.5/Linux-RHEL_4/include -I/home/users/sgent/TSVEG/ 
ACE_TAO/ACE_TAO_5_5_0/Linux-RHEL_4/include -I/usr/X11R6/include -I/ 
home/vr/Applications/TSVEG/Libraries/Release/Opt/VRJuggler-2.0.1- 
branch/Linux-RHEL4/include -I/home/vr/Applications/TSVEG/Libraries/ 
Release/Opt/cppdom-0.6.6/Linux-RHEL4/include -Ibuild.linux.2.0- 
redhat-4.i686.ia32/VE_Xplorer/GE/\/home\/vr\/Applications\/TSVEG\/ 
Libraries\/Release\/Opt\/GMTL\-0\.4\.12\/Linux\-RHEL4\/include - 
IVE_Xplorer/GE/\/home\/vr\/Applications\/TSVEG\/Libraries\/Release\/ 
Opt\/GMTL\-0\.4\.12\/Linux\-RHEL4\/include

Please note the last line with the gmtl include path. The pc file has  
the correct path but when scons parses the output from flagpoll it  
appears to butcher the gmtl include path. If I remove the \ from the  
include path in the gmtl pc file everything works fine. Is this an  
issue that can be resolved by changing the formating in the pc file  
or should this be addressed by scons? Also, I do not see this problem  
on my mac.

On the RHEL 4 machine:

|keymaker|~/svn_VE_Suite/VE_Suite> scons --version
SCons by Steven Knight et al.:
         script: v0.96.93.D001, 2006/11/06 08:31:54, by knight on  
roxbury
         engine: v0.96.93.D001, 2006/11/06 08:31:54, by knight on  
roxbury
Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation
|keymaker|~/svn_VE_Suite/VE_Suite>

On my mac:

objects:~ mccdo$ scons --version
SCons by Steven Knight et al.:
         script: v0.96.92.D002, 2006/04/11 07:39:43, by knight on  
roxbury
         engine: v0.96.92.D002, 2006/04/11 07:39:43, by knight on  
roxbury
Copyright (c) 2001, 2002, 2003, 2004 The SCons Foundation
objects:~ mccdo$

Thanks for the help.

Doug

Doug McCorkle - Research Assistant
Iowa State University
Virtual Engineering Research Group

Re: [ggt-devel] port file for gmtl

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

On Dec 30, 2006, at 7:57 PM, Doug McCorkle wrote:

> Hello,
>      I have been working on making a port file for gmtl for  
> darwinports/macports. If someone else who has a mac would be  
> willing to give it a try I would appreciate it. If it works well  
> should it be included in the gmtl repository? Thanks.
>
> Doug
>

There were issues with my previous Portfile that I posted. This one  
is working very well for me. I would like to have it submitted  
macports for inclusion in the distribution. What do you all think?

Doug

Re: [ggt-devel] port file for gmtl

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

On Dec 30, 2006, at 9:11 PM, Daniel E. Shipton wrote:

> On 12/30/06, Doug McCorkle <mc...@ia...> wrote:
> Hello,
>       I have been working on making a port file for gmtl for
> darwinports/macports. If someone else who has a mac would be willing
> to give it a try I would appreciate it. If it works well should it be
> included in the gmtl repository? Thanks.
>
>
> I don't know a whole lot about darwinports but wouldn't the port  
> file be submitted downstream to their repository?
>
> -Dan

I believe so but did not know if gmtl would also have a copy. Also, I  
am having problems with the archiving step in the port file so it  
will probably not work right yet. Everything installs properly by the  
registration part does not work properly.

Doug

Re: [ggt-devel] port file for gmtl

[Daniel E. S. <dan...@gm...>]

On 12/30/06, Doug McCorkle <mc...@ia...> wrote:
>
> Hello,
>       I have been working on making a port file for gmtl for
> darwinports/macports. If someone else who has a mac would be willing
> to give it a try I would appreciate it. If it works well should it be
> included in the gmtl repository? Thanks.



I don't know a whole lot about darwinports but wouldn't the port file be
submitted downstream to their repository?

-Dan

[ggt-devel] port file for gmtl

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

Hello,
      I have been working on making a port file for gmtl for  
darwinports/macports. If someone else who has a mac would be willing  
to give it a try I would appreciate it. If it works well should it be  
included in the gmtl repository? Thanks.

Doug

Re: [ggt-devel] new euk

[Jing R. <goi...@ce...>]

Hi
=20
FHARMACY economize more with http://polontinjerunhasdefunsa.com

=20

=20

=20

males soon became manic brick makers. After we showed them how to
build kilns, of course. There were contests to see who could mold the
most bricks, or fire the greatest number, or carry the most. The