<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 14-May-15 14:01, Nagy-Egri Máté
Ferenc via CMake wrote:<br>
</div>
<blockquote cite="mid:20150514150932.99665A93DE@public.kitware.com"
type="cite">
<meta name="generator" content="Windows Mail 17.5.9600.20856">
<style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst,
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle,
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style>
<div data-externalstyle="false" dir="ltr" style="font-family:
'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI',
'Microsoft JhengHei UI', 'Malgun Gothic',
'sans-serif';font-size:12pt;">
<div>This is more of a remark, or something to get the ball
rolling, rather than anything else.</div>
<div><br>
</div>
<div>I recently came across various FindModule.cmake files
(FindOpenCL, FindOpenGL, FindGLEW, FindGLM, FindSFML) as a
sideeffect of a project I am developing, but have had my share
with quite a few others (FindQt, RustCMake, FindOpenAL,
FindBoost, …). My overall impression is that the quality of
these modules is highly fluctuating to say the least. While
generally the FindModules shipping with CMake as built-in
scripts are usable, there is a fair amount of room for
improvement.</div>
<div><br>
</div>
<div>FindGLEW.cmake for eg. is terrible. I have never imagined
that such a widely used library has a 7 line FindModule
script. On Windows it is practically useless.</div>
<div><br>
</div>
<div>As for nearly all other FindModule scripts, nearly none of
them use target_include_libraries() that would allow for
end-users of the scripts to not have to worry about include
directories.</div>
<div><br>
</div>
<div>Some projects strive at being cross-platform, but compiling
them on Windows (mostly the GNU projects that aim on being
Windows friendly) is massive pain. libJPEG to name just one
provides nmake makefiles that are capable of producing Visual
Studio 2010 project files at best (huuraay), and have
undocumented external dependencies. These projects (and their
users) cry out for CMake support.</div>
<div><br>
</div>
<div>Here is a proposition to consider:</div>
</div>
</blockquote>
This sounds like a workaround for the existing problems. What we
really need to do to solve this issue completely is to use
automatically generated Find-like modules -
<Package>Config.cmake. See:
<a class="moz-txt-link-freetext" href="http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages">http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html#creating-packages</a>
<blockquote cite="mid:20150514150932.99665A93DE@public.kitware.com"
type="cite">
<div data-externalstyle="false" dir="ltr" style="font-family:
'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI',
'Microsoft JhengHei UI', 'Malgun Gothic',
'sans-serif';font-size:12pt;">
<div><br>
</div>
<div>Kitware generally has the philosphy with CMake being: do it
yourself or hire us to do it. While on a corporate basis this
is a legitimate approach, I as a poor academic fellow do not
have 10.000$ to spare for a feature I so wish, neither do I
have the time to educate myself in the internal ways of CMake
to contribute. So all I do is hack, hack, hack all day.</div>
<div><br>
</div>
<div>The Chocolatey project (a package manager for
Windows) recently won a massive Kickstarter campaign that
aimed solely increasing the overall quality of the project.
With this campaign they aimed on growing from an ‘interesting
idea’ to begin ‘mainstream’. With the money they won, they
hired full time package moderators, developed automated
scripts of facilitating authoring, wrote tutorials, created
templates, and even managed to get the ball rolling with
OneGet (Powershell 5.0 package manager manager) to adopt
Chocolatey as the first supported public repo.</div>
<div><br>
</div>
<div>I would suggest Kitware start a similar community funded
project to increase the overall quality of the software. While
I do not have 10 grands to buy a feature, I do have 10 dollars
pocket money to contribute (as do MANY others).</div>
<div><br>
</div>
<div>As several levels of goals, the stock FindModules scripts
could be brought to a homogenous quality, identical naming
conventions (no more MYLIB_INC_DIR, MYLIB_INCLUDE_DIRS,
MyLib_INCLUDE_DIR), high quality templates for new adopters,
make the CMake Guide freely available online (epub, pdf, docx,
whatever), convert 10 GNU projects to CMake, convert 50 GNU
projects to CMake, create Snappy back-end of CPack, or my
personal favorite (the feature I do not have 10.000 dollars
for) is NMake batch mode support for multicore build, etc.</div>
<div><br>
</div>
<div>There are so many places CMake itself can be improved, and
so many users who really should be adopting, but have not
started due to lacking man power. (These are the projects that
would benefit the most from a freely available tutorial,
because truth be told: writing capable, high-quality CMake
scripts is no easy task.)</div>
<div><br>
</div>
<div>If I were a charmismatic spokesperson I’d say: I RAISE 10
DOLLARS, WHO’S WITH ME?! But because I’m not, I’ll just leave
it here as a suggestion.</div>
<div><br>
</div>
<div>Ideas?<br>
</div>
</div>
</blockquote>
Have you seen <a class="moz-txt-link-freetext" href="https://www.bountysource.com/">https://www.bountysource.com/</a> ?<br>
<br>
Ruslo<br>
</body>
</html>