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