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