Add a new FindGperf module
ClosedPublic

Authored by pino on Dec 28 2016, 9:02 AM.

Details

Summary

Add a simple module to look for GNU gperf at build time, providing an
helper macro for adding generations to a list of sources.

gperf will be used to generate the C/C++ sources at build time, instead
of using static versions in VCS; at least kcodecs, khtml, and kio-extras
will be switched to this method.

Diff Detail

Repository
R240 Extra CMake Modules
Branch
pino-gperf
Lint
No Linters Available
Unit
No Unit Test Coverage
pino updated this revision to Diff 9408.Dec 28 2016, 9:02 AM
pino retitled this revision from to Add a new FindGperf module.
pino updated this object.
pino edited the test plan for this revision. (Show Details)
pino added a reviewer: Frameworks.

Windows and Mac people: at least from a quick glance, GNU gperf should be already available on Windows and Mac; can you please confirm the new (build time only) dependency could be acceptable?

adridg added a subscriber: adridg.Dec 28 2016, 11:40 AM

gperf is also available in the base system for FreeBSD, so this doesn't have any effects on the build there, either.

rjvbb added a subscriber: rjvbb.Dec 28 2016, 12:55 PM
In D3830#71722, @pino wrote:

Windows and Mac people: at least from a quick glance, GNU gperf should be already available on Windows and Mac

I can only speak for 10.9 but indeed, gperf is available in /usr/bin .

kfunk added a subscriber: kfunk.EditedDec 28 2016, 1:33 PM

Windows: We have a working gperf recipe in Craft => we're fine.

QtWebKit already had an (optional) dependency on gperf.

pino added a comment.Dec 28 2016, 1:42 PM

Cool -- thanks guys for the feedback on FreeBSD/Mac/Windows!

pino updated this revision to Diff 9499.Dec 30 2016, 4:42 PM

Use a full path for the output location.

Restricted Application added projects: Frameworks, Build System. · View Herald TranscriptDec 30 2016, 4:42 PM
pino updated this revision to Diff 9502.Dec 30 2016, 4:47 PM

Typo fix in previous revision.

rjvbb added a comment.Dec 30 2016, 5:17 PM

You're still determining the location from the path with this new revision, right?

pino added a comment.Dec 30 2016, 5:35 PM
In D3830#72502, @rjvbb wrote:

You're still determining the location from the path with this new revision, right?

For the input file? Yes.

rjvbb added a comment.Dec 31 2016, 8:56 AM
In D3830#72508, @pino wrote:

For the input file? Yes.

I did mean the gperf executable...!

pino added a comment.Dec 31 2016, 9:45 AM
In D3830#72696, @rjvbb wrote:
In D3830#72508, @pino wrote:

For the input file? Yes.

I did mean the gperf executable...!

I don't get what you mean, sorry :/ The full path of gperf is determined using find_program, which looks in $PATH -- you can always specify the variable with the full path to force a custom location.

rjvbb added a comment.Dec 31 2016, 9:54 AM
In D3830#72701, @pino wrote:

The full path of gperf is determined using find_program, which looks in $PATH -- you can always specify the variable with the full path to force a custom location.

great, that's exactly what I thought but wanted to see confirmed! :)
(your remark of "using the full path for the output location" confused me a bit, sorry about that)

rjvbb accepted this revision.Apr 5 2017, 7:24 AM

Sorry, I haven't had the occasion to test this modification but given our exchange above this ought to be fine as far as I can tell.

This revision is now accepted and ready to land.Apr 5 2017, 7:24 AM
adridg accepted this revision.Apr 5 2017, 10:17 AM

I just happened to need a FindGperf in another project today, so I've tested this in non-ECM settings (adding this plus ECMFindModuleHelpers to that project's own cmake/) and it works fine on FreeBSD. The docs in the header are good, too: they let me replace some custom cruft in under five minutes with simpler ECM code.

So from the FreeBSD side: ship it.

This revision was automatically updated to reflect the committed changes.