Review Request 119275: Fix: Same variable in camelCase and REQUIRED_HEADERS doesn't export all headers

[Andreas Xavier]

> On July 14, 2014, 10:57 p.m., Aleix Pol Gonzalez wrote:
> > Is this because of the usage of list(APPEND)? Maybe using set(.. PARENT_SCOPE) for appending would do the trick as well?
> 
> Andreas Xavier wrote:
>     Can you confirm that you are seeing the same problem?  
>     
>     This is my first time trying to compile KF5 and the problem is most likely to be with my setup.  
>     
>     If I know that everyone is experiencing the problem, then I will try to fix it in ecm using set( .. PARENT_SCOPE).
> 
> Cristian Oneț wrote:
>     I remember running into something similar while building using kdesrc-build. I just suspected that it's something related to my setup since it went away once I manually ran 'make install' from the build directory created by kdesrc-build.
>     While building on Windows using emerge I didn't see this though.
> 
> Alex Merry wrote:
>     I can't reproduce this (and, additionally, the [CI system](http://build.kde.org) does a completely clean build and install every time). Can you post the output of `cmake --version`, please?

Entirely my mistake.  All of frameworks compiled with no changes.

Thank you for taking the time to look at this.

I am now running with :
cmake version 3.0.20140712-g2eadd1

One nameless Konsole tab over I was running with : 
cmake version 2.8.12.2

It might be worth noting that with the changes in this patch cmake 2.8.12.2 was able to compile frameworks all the way to KHTML with no complaints.  Clearly, I am a cmake novice, but if this patch doesn't break the build with 3.0 and it makes it possible to build it with 2.8.12.2 it might make the overall build more robust.

Once again thanks for your time.


- Andreas


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


On July 14, 2014, 6 p.m., Andreas Xavier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119275/
> -----------------------------------------------------------
> 
> (Updated July 14, 2014, 6 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Michael Pyne.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> -------
> 
> Using the same variable name for var1 and var2 in the new ecm_generate_headers() syntax, when it is called more than once only exports the headers from the first invokation of ecm_generate_headers(), where var1 and var2 are defined as follows.
> 
> ecm_generate_headers(var1
> ...
>     REQUIRED_HEADERS var2
> )
> 
> It doesn't show up in existing builds because cmake doesn't delete old header files.
> 
> 
> Steps to Replicate the Problem:
> 1. Delete the existing header files for KCoreAddons and the existing build files.
>    rm -r $KF5/KcoreAddons
>    rm -r <your kcoreaddons/build directory>
> 2. Re-build kcoreaddons from a new build dir
>    cmake -DCMAKE_INSTALL_PREFIX=$KF5 ..
> 3. Check in $KF5/KcoreAddons and there should only be these headers:
>    KAboutData  kaboutdata.h  kcoreaddons_export.h
>    
>    
> Solution:
> This patch solves the problem by changing the name of var2 to KCoreAddons_HEADERS_lowercase and exporting both KCoreAddons_HEADERS and KCoreAddons_HEADERS_lowercase.
> 
> Extended Solution:
> If this patch is approved, then I will 
> 1. Submit patches to the other frameworks using ecm_generate_headers() in this fashion.
> 2. submit a patch to extra-cmake-modules to warn when var1 and var2 have the same name. 
> 
> 
> Diffs
> -----
> 
>   src/lib/CMakeLists.txt 26eb5a1 
> 
> Diff: https://git.reviewboard.kde.org/r/119275/diff/
> 
> 
> Testing
> -------
> 
> Compiled kcoreaddons, then checked that all headers generated and exported.
> 
> Ran unittests.
> 
> 
> Thanks,
> 
> Andreas Xavier
> 
>

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