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

Fri Sep 30 15:34:41 UTC 2016


> On May 3, 2016, 2:42 p.m., Aleix Pol Gonzalez wrote:
> > 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.
> 
> René J.V. Bertin wrote:
>     Hah...
>     
>     The principal applies universally of course, to all filesystems that will silently accept to replace an existing directory entry with another one of the same type that differs only in name case.
>     
>     I was going to reply that I'd only seen the issue express itself with attica (and in bug reports only; I use a case-sensitive HFS partition for development). But a quick check shows that Solid and Sonnet follow the same unreliable install layout, and they're not exactly alone:
>     
>     ``` > find /opt/local/include/KF5/ -mindepth 2 -maxdepth 2 -a -type d
>     /opt/local/include/KF5/KDNSSD/dnssd
>     /opt/local/include/KF5/KDNSSD/DNSSD
>     /opt/local/include/KF5/BalooWidgets/baloo
>     /opt/local/include/KF5/BalooWidgets/Baloo
>     /opt/local/include/KF5/Attica/attica
>     /opt/local/include/KF5/Attica/Attica
>     /opt/local/include/KF5/KIOGui/KIO
>     /opt/local/include/KF5/KIOGui/kio
>     /opt/local/include/KF5/Solid/solid
>     /opt/local/include/KF5/Solid/Solid
>     /opt/local/include/KF5/KUnitConversion/KUnitConversion
>     /opt/local/include/KF5/KUnitConversion/kunitconversion
>     /opt/local/include/KF5/KIOWidgets/KIO
>     /opt/local/include/KF5/KIOWidgets/kio
>     /opt/local/include/KF5/KDeclarative/QuickAddons
>     /opt/local/include/KF5/KDeclarative/quickaddons
>     /opt/local/include/KF5/KDeclarative/kdeclarative
>     /opt/local/include/KF5/KDeclarative/calendarevents
>     /opt/local/include/KF5/KDeclarative/KQuickAddons
>     /opt/local/include/KF5/KDeclarative/KDeclarative
>     /opt/local/include/KF5/KDeclarative/CalendarEvents
>     /opt/local/include/KF5/KDeclarative/kquickaddons
>     /opt/local/include/KF5/KNewStuff3/KNS3
>     /opt/local/include/KF5/KNewStuff3/kns3
>     /opt/local/include/KF5/KPackage/KPackage
>     /opt/local/include/KF5/KPackage/kpackage
>     /opt/local/include/KF5/KXmlRpcClient/KXmlRpcClient
>     /opt/local/include/KF5/KXmlRpcClient/kxmlrpcclient
>     /opt/local/include/KF5/ThreadWeaver/ThreadWeaver
>     /opt/local/include/KF5/ThreadWeaver/threadweaver
>     /opt/local/include/KF5/KExiv2/kexiv2
>     /opt/local/include/KF5/KExiv2/KExiv2
>     /opt/local/include/KF5/SonnetUi/sonnet
>     /opt/local/include/KF5/SonnetUi/Sonnet
>     /opt/local/include/KF5/KActivities/KActivities
>     /opt/local/include/KF5/KActivities/kactivities
>     /opt/local/include/KF5/KIOCore/kio
>     /opt/local/include/KF5/KIOCore/KIO
>     /opt/local/include/KF5/SonnetCore/sonnet
>     /opt/local/include/KF5/SonnetCore/Sonnet
>     /opt/local/include/KF5/KParts/KParts
>     /opt/local/include/KF5/KParts/kparts
>     /opt/local/include/KF5/purpose/purpose
>     /opt/local/include/KF5/purpose/Purpose
>     /opt/local/include/KF5/Baloo/baloo
>     /opt/local/include/KF5/Baloo/Baloo
>     /opt/local/include/KF5/KRunner/KRunner
>     /opt/local/include/KF5/KRunner/krunner
>     /opt/local/include/KF5/KFileMetaData/kfilemetadata
>     /opt/local/include/KF5/KFileMetaData/KFileMetaData
>     /opt/local/include/KF5/KTextEditor/KTextEditor
>     /opt/local/include/KF5/KTextEditor/ktexteditor
>     /opt/local/include/KF5/KDESu/KDESu
>     /opt/local/include/KF5/KDESu/kdesu
>     /opt/local/include/KF5/KPeople/kpeoplebackend
>     /opt/local/include/KF5/KPeople/KPeople
>     /opt/local/include/KF5/KPeople/kpeople
>     /opt/local/include/KF5/KPeople/KPeopleBackend
>     /opt/local/include/KF5/purposewidgets/PurposeWidgets
>     /opt/local/include/KF5/purposewidgets/purposewidgets
>     ```
>     
>     I started a topic on the KDE-Frameworks ML ("case in filenames"), this RR is a result of that.
>     Maybe a general solution should be discussed on there before I or anyone else starts patching all those frameworks, esp. if I'm not the only one who's run into it.
>     
>     Maybe it'd be possible to wrap the "CamelCase" logic in ECM? Attica's build system was easy enough to patch; I doubt things will be so trivial in all cases.

FYI:
https://bugs.kde.org/show_bug.cgi?id=369554


- René J.V.


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


On May 3, 2016, 3:29 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, 3:29 p.m.)
> 
> 
> Review request for Build System, 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-buildsystem/attachments/20160930/c283ffdb/attachment.html>