Review Request 122317: Extend ecm_generate_headers macro to also support CamelCase.h headers

[Friedrich W. H. Kossebau]

> On Feb. 15, 2015, 5:46 nachm., Alex Merry wrote:
> > modules/ECMGenerateHeaders.cmake, lines 131-133
> > <https://git.reviewboard.kde.org/r/122317/diff/2/?file=347076#file347076line131>
> >
> >     Rather than artificially add yet another place to change when we introduce new variants, why not just make this part of the if/else statement in lines 148-152 below?
> 
> Friedrich W. H. Kossebau wrote:
>     Because, if EGH_PREFIX is not set, then the lines in 148-152 will not be reached. But EGH_ORIGINAL must be always checked if a proper value is set.
>     So needs to be done outside that if/else.
> 
> Alex Merry wrote:
>     Ah, you're right, my bad. It could go in the foreach, but there's certainly no need to check it every single iteration of the loop; OTOH, the maintainability of not having yet another thing to change with a new mode may outweigh the runtime cost of an extra string test in the loop.
>     
>     I'll leave it up to you whether you want to make that change, though, as I don't feel too strongly either way.

K. Will leave it as it is as I prefer sanity checks to be at the begin, not "hidden" in the rest of the code (I need/prefer simple structures, with one place doing one thing, even if longer :) )
Also if the new variants come, the code might change differently from what we expect now (perhaps there could be a separate method generate_original_filename getting the EGH_ORIGINAL as paramter), so leaving code optimization to the person adding the variants and their needs.


- Friedrich W. H.


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


On Feb. 14, 2015, 4:11 nachm., Friedrich W. H. Kossebau wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122317/
> -----------------------------------------------------------
> 
> (Updated Feb. 14, 2015, 4:11 nachm.)
> 
> 
> Review request for Build System, Extra Cmake Modules and Alex Merry.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> -------
> 
> There are at least two projects I know which have CamelCase.h headers, Calligra and KDChart. Still it would be nice to also allow pure CamelCase headers (suffix less) for usage by lib-using developers. Just, currently the macro ecm_generate_headers assumes the original headers to be lowercase. So it cannot be used for the mentioned projects.
> Worse, ecm_generate_headers also has a very nice additional feature, having copies of the original headers in the build dir created with the same layout as there will be after installation, so e.g. code of demos and tests can be written as if it is 3rd-party outside the project.
> 
> Attached patch extends ecm_generate_headers to support an optional parameter `ORIGINAL` (perhaps a better term could be found), by which the casing of the original headers can be specified. Currently `CAMELCASE` and `LOWERCASE` are supported. But perhaps one day someone could extend it for underscore-casing :). The parameter defaults to `LOWERCASE` and thus should be backwards portable.
> 
> Tested also with prefixes.
> 
> Not sure the assumption that the original prefix has the same casing as the original headers, I remember to have seen code where that is not consistent. But that step to implement is left for those persons who really need it ;)
> 
> Update:
> See also discussion at https://git.reviewboard.kde.org/r/122193/ where so far opinions are positive on this one.
> 
> 
> Diffs
> -----
> 
>   modules/ECMGenerateHeaders.cmake bac5086 
>   tests/ECMGenerateHeadersTest/CamelCaseHeadTest1.h PRE-CREATION 
>   tests/ECMGenerateHeadersTest/CamelCaseHeadTest2.h PRE-CREATION 
>   tests/ECMGenerateHeadersTest/run_test.cmake.config 0a2425f 
> 
> Diff: https://git.reviewboard.kde.org/r/122317/diff/
> 
> 
> Testing
> -------
> 
> Manually and in latest update also with 2 unit tests (hm, not sure if those tests should cover more combinations with other parameters).
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20150215/736ebc72/attachment.html>