Review Request 127822: address the potential name/case clash of the Attica/Attica and Attica/attica header dirs

Aleix Pol Gonzalez aleixpol at kde.org
Tue May 3 12:42:05 UTC 2016


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127822/#review95135
-----------------------------------------------------------



Is this specific to Attica or it will happen on other frameworks? I have a memory of having such an issue worked on at some point.

- Aleix Pol Gonzalez


On May 3, 2016, 2 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127822/
> -----------------------------------------------------------
> 
> (Updated May 3, 2016, 2 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: attica
> 
> 
> Description
> -------
> 
> Attica has long adhered to an install layout that relies on case to distinguish directories. For instance:
> 
> ```
> include/KF5/Attica/Attica/AccountBalance
> include/KF5/Attica/attica/accountbalance.h
> ```
> 
> Depending on the order in which those files are installed on a FS like HFS+ (in case-insensitive-but-case-preserving mode), you will end up with `Attica/Attica` or `Attica/attica` directories; the directory name case changes to reflect the last write.
> 
> Basic calls like fopen() will succeed regardless of case because the filesystem ignores case in such operations. However, compilers (clang at least) do not simply try to open a requested include file in each element of the header directory search path. They use a search algorithm to locate the file first ... and that algorithm takes case into account. So `#include <Attica/AccountBalance>` will fail if the file is installed as `include/KF5/Attica/attica/AccountBalance`.
> 
> This issue is delicate to fix: the most trivial solution (installing all headers in a single directory) would still require changes in all dependent code.
> 
> I'm just proposing a fix that builds on the assumption that the `<Attica/Foo>` style is part of C++ semantics (as opposed to a more traditional `<attica/foo.h>`). The fix installs headers in `KF5/Attica/attica` and `KF5/Attica/c++/Attica`, and adds the additional `Attica/c++` component to the header search path. It also corrects the pkg-config file.
> 
> 
> Diffs
> -----
> 
>   src/CMakeLists.txt 984f7ff 
>   src/cmake/libKF5Attica.pc.cmake 75387fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127822/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.9.5 with FWs. 5.20.0 installed under /opt/local . As a test-case I rebuilt `knewstuff` after changing its `src/uploaddialog_p.h` to include `<Attica/ListJob>` instead of `<attica/listjob.h>` and `<Attica/Provider>` instead of `<attica/provider.h>`.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160503/85dc571c/attachment.html>


More information about the Kde-frameworks-devel mailing list