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/