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/