[cfe-dev] Relative Paths in Compilation Database

Fri Apr 3 16:12:19 PDT 2015

On Fri, Apr 3, 2015 at 3:57 PM, Daniel Dilts <diltsman at gmail.com> wrote:

> Unfortunately this approach can be a significant burden on Windows, since
> it isn't always obvious from programmatic inspection what is and isn't a
> file path.
>
>

Therefore , enforcing forward slashes in file names in every environment is
more suitable .

Mehmet Erol Sanliturk

> On Fri, Apr 3, 2015 at 3:32 PM, Mehmet Erol Sanliturk <
> m.e.sanliturk at gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 3, 2015 at 3:07 PM, Daniel Dilts <diltsman at gmail.com> wrote:
>>
>>> You are correct.  Forward slashes can be substituted for backslashes in
>>> many cases, but many compilation databases will be generated with
>>> backslashes.  Either we mandate that only forward slashes can be used, or
>>> CommandLineArgumentParser must be fixed.
>>>
>>> I am willing and able to make the fixes, but I don't know how to test
>>> for the platform so that the correct set of escapes are used.
>>>
>>>
>>
>>
>> In Unix world , back slash is used for escape character .
>> In Windows , in file names , back and forward slashes are usable .
>> Their intersection is forward slash .
>>
>> My opinion is that enforcing forward slashes in file names is more
>> suitable .
>> Otherwise , always will be necessary to use escape back slash for Windows
>> file names which is not a convenient form ( In Windows  always will be
>> necessary to clear additional back slashes before submitting it to
>> operating system routines ) .
>>
>> Fixing CommandLineArgumentParser also may be a very convenient action :
>> For file names , forward and backward slashes may be treated equivalent
>> without using escape back slash .
>> For back slash used file names , when they are used in Unix environments
>> , they may be directly converted to forward slashes .
>>
>>
>> Lazarus and Free Pascal is using this form since , I think , their
>> starting time . When this form is used ( forward or back slashes ) ,
>> conversion of them in Unix by the compiler is the most convenient way ( in
>> Windows there is no any need to such a conversion in sources ) .
>>
>> I did not use Visual Studio , but , I am compiling sources in Unix (
>> FreeBSD , Linux ) compilable in Visual Studio without any trouble for
>> forward slashes ( means Visual Studio is able to accept these , but please
>> test this for exact decision ) .
>>
>>
>>
>> Mehmet Erol Sanliturk
>>
>>
>>
>>
>>
>>> On Fri, Apr 3, 2015 at 2:43 PM, Mehmet Erol Sanliturk <
>>> m.e.sanliturk at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Apr 3, 2015 at 1:54 PM, Daniel Dilts <diltsman at gmail.com>
>>>> wrote:
>>>>
>>>>> I finally had the opportunity to look into this.
>>>>>
>>>>> CommandLineArgumentParser in JSONCompilationDatabase.cpp deals with
>>>>> escapes by discarding all backslash characters.  I imagine that this works
>>>>> pretty well on Linux, not perfectly, but well enough.
>>>>>
>>>>> Windows uses backslash as a separator in file paths, so this breaks
>>>>> most file paths on Windows.
>>>>>
>>>>> How would one go about fixing this so it works on both Windows and
>>>>> Linux?  Obviously the different escape sequences need to be implemented.
>>>>> What I really mean is, how do you make it so that it uses the correct set
>>>>> of escapes depending on platform?
>>>>>
>>>>>
>>>>> On Tue, Mar 17, 2015 at 12:57 PM, Manuel Klimek <klimek at google.com>
>>>>> wrote:
>>>>>
>>>>>> I haven't had time to look.
>>>>>>
>>>>>> On Tue, Mar 17, 2015 at 6:06 PM Daniel Dilts <diltsman at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> What appears to be the exact problem?  Are relative paths just not
>>>>>>> properly implemented, or is the problem more specific than that?
>>>>>>>
>>>>>>> On Tue, Mar 17, 2015 at 4:07 AM, Manuel Klimek <klimek at google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I think this is a known problem. Patches very welcome :)
>>>>>>>>
>>>>>>>> On Tue, Mar 17, 2015 at 1:14 AM Daniel Dilts <diltsman at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I am calling runClangTidy using a JSONCompilationDatabase that I
>>>>>>>>> generate from a string.  Everything works perfectly until I have a relative
>>>>>>>>> path.
>>>>>>>>>
>>>>>>>>> With the following database I use
>>>>>>>>> "D:\\CMakeTest\\bld\\..\\src\\main.cpp" as the file to open:
>>>>>>>>> [
>>>>>>>>>    {
>>>>>>>>>       "directory": "D:\\CMakeTest\\bld\\",
>>>>>>>>>       "command"  : "D:/llvm/build/Debug/bin/clang.exe
>>>>>>>>> -I\"C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\include\"
>>>>>>>>> -I\"C:\\Program Files (x86)\\Microsoft Visual Studio
>>>>>>>>> 12.0\\VC\\atlmfc\\include\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\um\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\shared\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\winrt\"   -I\"C:\\Program Files (x86)\\Microsoft Visual
>>>>>>>>> Studio 12.0\\VC\\include\" -I\"C:\\Program Files (x86)\\Microsoft Visual
>>>>>>>>> Studio 12.0\\VC\\atlmfc\\include\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\um\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\shared\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\winrt\"   -DWIN32 -D_WINDOWS -D_DEBUG
>>>>>>>>> -DCMAKE_INTDIR=\"Debug\" ..\\src\\main.cpp",
>>>>>>>>>       "file"     : "..\\src\\main.cpp"
>>>>>>>>>    },
>>>>>>>>> ]
>>>>>>>>>
>>>>>>>>> This gives me an output of "Error while processing
>>>>>>>>> D:\\CMakeTest\\bld\\..\\src\\main.cpp."
>>>>>>>>>
>>>>>>>>> When I use the following database with
>>>>>>>>> "D:\\CMakeTest\\src\\main.cpp" as the file to open, everything works.
>>>>>>>>>
>>>>>>>>> [
>>>>>>>>>    {
>>>>>>>>>       "directory": "D:\\CMakeTest\\src\\",
>>>>>>>>>       "command"  : "D:/llvm/build/Debug/bin/clang.exe
>>>>>>>>> -I\"C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\include\"
>>>>>>>>> -I\"C:\\Program Files (x86)\\Microsoft Visual Studio
>>>>>>>>> 12.0\\VC\\atlmfc\\include\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\um\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\shared\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\winrt\"   -I\"C:\\Program Files (x86)\\Microsoft Visual
>>>>>>>>> Studio 12.0\\VC\\include\" -I\"C:\\Program Files (x86)\\Microsoft Visual
>>>>>>>>> Studio 12.0\\VC\\atlmfc\\include\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\um\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\shared\" -I\"C:\\Program Files (x86)\\Windows
>>>>>>>>> Kits\\8.1\\Include\\winrt\"   -DWIN32 -D_WINDOWS -D_DEBUG
>>>>>>>>> -DCMAKE_INTDIR=\"Debug\" main.cpp",
>>>>>>>>>       "file"     : "main.cpp"
>>>>>>>>>    },
>>>>>>>>> ]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is there something that I am doing wrong?  The only changes
>>>>>>>>> between the two compilation databases are the directory and file entries.
>>>>>>>>> Both should refer to the same absolute path.
>>>>>>>>> _______________________________________________
>>>>>>>>> cfe-dev mailing list
>>>>>>>>> cfe-dev at cs.uiuc.edu
>>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> In Windows , forward slashes in source files are usable :
>>>>
>>>> include '/a/b/....'  ( relative paths can be used such as ../../../
>>>> etc. )
>>>>
>>>> ( I am using this form , at least since ten years because I am
>>>> compiling the same program sources in Windows and Unix without any change ,
>>>> in Fortran , Pascal , and C  )
>>>>
>>>> but , in Console , only back slashes are accepted :
>>>>
>>>> dir \a\b\... /S
>>>> ren \a\b\d\g.c  h.c
>>>>
>>>> because , forward slashes are used for command line options .
>>>>
>>>> I did not try forward slashes in quoted form : You may try it ( I do
>>>> not have any Windows at present ) :
>>>>
>>>> dir "/a/b/..." /S
>>>>
>>>>
>>>>
>>>> Thank you very much .
>>>>
>>>>
>>>>
>>>> Mehmet Erol Sanliturk
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150403/b990f7c8/attachment.html>