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/