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

[René J . V . Bertin]

> On May 11, 2016, 4:05 p.m., René J.V. Bertin wrote:
> > src/CMakeLists.txt, lines 160-163
> > 
> >
> > This change is problematic, and apparently needs to be 
> > platform-specific (if done here):
> > 
> > - on OS X it works as intended, despite the fact one should use 
> > `INCLUDES DESTINATION` instead of `INCLUDES` alone
> > - on Linux, it adds an additional path to the search path 
> > ($PREFIX/INCLUDES), which raises an error if inexistent. The intended 
> > behaviour is obtained by removing the `INCLUDES` keyword.
> > 
> > This is probably because of this extract from 
> > `ECM/KDEInstallDirs.cmake`:
> > 
> > ```
> > set(KF5_INSTALL_TARGETS_DEFAULT_ARGS  RUNTIME DESTINATION 
> > "${CMAKE_INSTALL_BINDIR}"
> >   LIBRARY DESTINATION 
> > "${CMAKE_INSTALL_LIBDIR}"
> >   ARCHIVE DESTINATION 
> > "${CMAKE_INSTALL_LIBDIR}" COMPONENT Devel
> >   INCLUDES DESTINATION 
> > "${CMAKE_INSTALL_INCLUDEDIR_KF5}"
> > )
> > 
> > # on the Mac support an extra install directory for application bundles
> > if(APPLE)
> > set(KDE_INSTALL_TARGETS_DEFAULT_ARGS  
> > ${KDE_INSTALL_TARGETS_DEFAULT_ARGS}
> >   BUNDLE DESTINATION 
> > "${BUNDLE_INSTALL_DIR}" )
> > set(KF5_INSTALL_TARGETS_DEFAULT_ARGS  
> > ${KF5_INSTALL_TARGETS_DEFAULT_ARGS}
> >   BUNDLE DESTINATION 
> > "${BUNDLE_INSTALL_DIR}" )
> > endif()
> > ```
> > 
> > IOW, it *may* be that OS X ("APPLE") requires a dedicated change to 
> > `src/CMakelists.txt`, or else there'd be special cases for OS X, MSWin and 
> > the default (anything that always has a case-sensitive platform).
> > 
> > I don't see an alternative, except possibly at the level of 
> > `CMAKE_INSTALL_INCLUDEDIR_KF5`, but I cannot find where that variable is 
> > defined.

I realise that the above comment isn't very clear. First: the INSTALL() 
documentation instructs to use `INCLUDES DESTINATION` while what works (on Mac 
OS) is to use `INCLUDES` alone, as written in the patch. Why is unclear to me.

The difference with Linux becomes clear when we look at 
`KF5_INSTALL_TARGETS_DEFAULT_ARGS`:
- Linux : 
`RUNTIME;DESTINATION;bin;LIBRARY;DESTINATION;lib/x86_64-linux-gnu;ARCHIVE;DESTINATION;lib/x86_64-linux-gnu;COMPONENT;Devel;INCLUDES;DESTINATION;include/KF5`
- OS X : 
`RUNTIME;DESTINATION;bin;LIBRARY;DESTINATION;lib;ARCHIVE;DESTINATION;lib;COMPONENT;Devel;INCLUDES;DESTINATION;include/KF5;BUNDLE;DESTINATION;/Applications/MacPorts/KF5`

IOW, on Linux the additional path can be appended directly to the preexisting 
`INCLUDES DESTINATION`, whereas on OS X there are additional elements in the 
list which make that impossible. 

I tried adding the `BUNDLE DESTINATION` to `KF5_INSTALL_TARGETS_DEFAULT_ARGS` 
unconditionally and that makes the attached patch work as expected on Linux too.

Of course it would be more elegant to have a macro to modify 
`KF5_INSTALL_TARGETS_DEFAULT_ARGS` and add additional paths to `INCLUDES 
DESTINATION`.

Or some other method to add elements to the `INTERFACE_INCLUDE_DIRECTORIES` 
variable defined by the frameworks' `KF5*Targets.cmake` module.


- René J.V.


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


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 
> ` w

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

[René J . V . Bertin]

> 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

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

[René J . V . Bertin]

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




src/CMakeLists.txt (lines 160 - 163)


This change is problematic, and apparently needs to be platform-specific 
(if done here):

- on OS X it works as intended, despite the fact one should use `INCLUDES 
DESTINATION` instead of `INCLUDES` alone
- on Linux, it adds an additional path to the search path 
($PREFIX/INCLUDES), which raises an error if inexistent. The intended behaviour 
is obtained by removing the `INCLUDES` keyword.

This is probably because of this extract from `ECM/KDEInstallDirs.cmake`:

```
set(KF5_INSTALL_TARGETS_DEFAULT_ARGS  RUNTIME DESTINATION 
"${CMAKE_INSTALL_BINDIR}"
  LIBRARY DESTINATION 
"${CMAKE_INSTALL_LIBDIR}"
  ARCHIVE DESTINATION 
"${CMAKE_INSTALL_LIBDIR}" COMPONENT Devel
  INCLUDES DESTINATION 
"${CMAKE_INSTALL_INCLUDEDIR_KF5}"
)

# on the Mac support an extra install directory for application bundles
if(APPLE)
set(KDE_INSTALL_TARGETS_DEFAULT_ARGS  
${KDE_INSTALL_TARGETS_DEFAULT_ARGS}
  BUNDLE DESTINATION 
"${BUNDLE_INSTALL_DIR}" )
set(KF5_INSTALL_TARGETS_DEFAULT_ARGS  
${KF5_INSTALL_TARGETS_DEFAULT_ARGS}
  BUNDLE DESTINATION 
"${BUNDLE_INSTALL_DIR}" )
endif()
```

IOW, it *may* be that OS X ("APPLE") requires a dedicated change to 
`src/CMakelists.txt`, or else there'd be special cases for OS X, MSWin and the 
default (anything that always has a case-sensitive platform).

I don't see an alternative, except possibly at the level of 
`CMAKE_INSTALL_INCLUDEDIR_KF5`, but I cannot find where that variable is 
defined.


- René J.V. Bertin


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 
> ` 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 
> `` style is part of C++ semantics (as opposed to a more 
> traditional ``). 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 
> `` instead of `` and `` 
> instead of ``.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[René J . V . Bertin]

> 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.

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.


- 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, 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 

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

[Aleix Pol Gonzalez]

---
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 
> ` 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 
> `` style is part of C++ semantics (as opposed to a more 
> traditional ``). 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 
> `` instead of `` and `` 
> instead of ``.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[René J . V . Bertin]

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

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 
` 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 `` 
style is part of C++ semantics (as opposed to a more traditional 
``). 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 
`` instead of `` and `` 
instead of ``.


Thanks,

René J.V. Bertin

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel