<div dir="ltr">Hi all,<div><br></div><div>How does the cmake project decide on new features?<br></div><div><br></div><div>Thread summary/history:</div><div><br></div><div>Thomas Richard wrote: </div><div>> <span style="color:rgb(0,0,0)">Being able of using a <a href="http://android.mk">android.mk</a> generator would be the perfect solution.</span></div>
<div><span style="color:rgb(0,0,0)"><br></span></div><div>Vince Harron wrote:</div><div>> <span style="color:rgb(0,0,0)">I would also like to see support for generating Android.mk files from CMake.</span></div><div><br>
</div><div>Stephen Kelly wrote:</div><div>> <span style="color:rgb(0,0,0);white-space:pre-wrap">I don't decide whether such a generator gets in or not, but I don't see why </span><span style="color:rgb(0,0,0);white-space:pre-wrap">it would not be accepted.</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Eric Wing wrote:</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">> </span><span style="color:rgb(0,0,0);white-space:pre-wrap">I agree that we should have a “native” Android NDK build generator.</span></div>
<div><br></div><div>Details:</div><div><div><a href="http://public.kitware.com/pipermail/cmake-developers/2014-January/009347.html">http://public.kitware.com/pipermail/cmake-developers/2014-January/009347.html</a><br></div>
<div><a href="http://public.kitware.com/pipermail/cmake-developers/2014-January/009394.html">http://public.kitware.com/pipermail/cmake-developers/2014-January/009394.html</a><br></div></div><div><br></div><div>The question is, how does the cmake project decide on new features?  Before I begin implementation, I would like to know definitively that this would be accepted if implemented properly.  </div>
<div><br></div><div>Eric Wing is on the CMake participant's page under "CMake Module maintainers and developers:" is his agreement enough or is there another process?</div><div><br></div><div><a href="http://cmake.org/cmake/project/parti.html">http://cmake.org/cmake/project/parti.html</a> </div>
<div><br></div><div>Thanks for your guidance.</div><div><br></div><div>Sincerely,</div><div><br></div><div>Vince</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 13, 2014 at 7:23 AM,  <span dir="ltr"><<a href="mailto:cmake-developers-request@cmake.org" target="_blank">cmake-developers-request@cmake.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Message-ID: <lb0kh6$mhf$<a href="mailto:1@ger.gmane.org">1@ger.gmane.org</a>><br>
<br>
Eric Wing wrote:<br>
<br>
> On 1/10/14, Stephen Kelly<br>
> <<a href="mailto:steveire@gmail.com">steveire@gmail.com</a>> wrote:<br>
>> Vince Harron wrote:<br>
>><br>
>>> Android.mk files allow you to target multiple processor<br>
>>> architectures/variants in one make invocation without any reconfiguring<br>
>>> or<br>
>>> multiple build folders.  All of those binaries are embedded into one<br>
>>> "fat"<br>
>>> apk file that will run on any supported Android device.<br>
>><br>
>> Sounds interesting.<br>
>><br>
>>>> Modules/Platform/Android.cmake<br>
>>><br>
>>> I've just started playing with it like this as my Android.cmake<br>
>>><br>
>>> include(Platform/Linux)<br>
>>><br>
>>> But it's critical to have Android as a separate CMAKE_SYSTEM_NAME<br>
>>> because there are many differences that you might want to switch on.<br>
>><br>
>> Indeed. Disabling SONAME is another apparently:<br>
>><br>
>>  <a href="http://public.kitware.com/Bug/view.php?id=14602" target="_blank">http://public.kitware.com/Bug/view.php?id=14602</a><br>
>><br>
>>>> Why does that link also say that Android.mk files are only for creating<br>
>>> shared and static libraries? Am I missing something here?<br>
>>><br>
>>> All Android applications start life as Java processes.  A java process<br>
>>> can<br>
>>> load a native shared library and invoke code within it.  To emit a C/C++<br>
>>> executable on Android is the same as to emit a shared library, but<br>
>>> linked to something called the native_app_glue module.<br>
>><br>
>> Interesting. What is the entry point?<br>
>><br>
>><br>
>> I don't decide whether such a generator gets in or not, but I don't see<br>
>> why<br>
>><br>
>> it would not be accepted.<br>
>><br>
>> Thanks,<br>
>><br>
>> Steve.<br>
>><br>
><br>
> I agree that we should have a ?native? Android NDK build generator.<br>
> There are some things that are harder to do outside the native build<br>
> process (some which have already been identified in this thread)<br>
><br>
> - Multiple architecture support (armeabi, armeabi-v7a, x86, mips).<br>
<br>
Though not directly related, it would be good to have<br>
<br>
 <a href="http://public.kitware.com/Bug/view.php?id=14539" target="_blank">http://public.kitware.com/Bug/view.php?id=14539</a><br>
<br>
in mind when implementing this generator for future consideration and so<br>
that the features don't conflict with each other.<br>
<br>
> - I?m not sure if this is the SONAME example mentioned, but Android<br>
> can?t handle the .so version numbering scheme where version numbers<br>
> are put in the file name and symlinks are used to point a version-less<br>
> file to a specific version. The NDK design is to use Java?s<br>
> System.loadLibrary to load NDK modules, and it turns out that<br>
> loadLibrary can?t handle symlinks.<br>
<br>
Yes, this is the issue I meant, but I didn't know the detail or reasons<br>
behind it, thanks.<br>
<br>
<br>
Thanks,<br>
<br>
Steve.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 13 Jan 2014 13:36:03 +0100<br>
From: "Daniele E. Domenichelli" <<a href="mailto:daniele.domenichelli@gmail.com">daniele.domenichelli@gmail.com</a>><br>
To: <a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a><br>
Subject: Re: [cmake-developers] RFC: add version to project() call<br>
Message-ID: <<a href="mailto:52D3DDB3.5010709@gmail.com">52D3DDB3.5010709@gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 10/01/14 21:19, Alexander Neundorf wrote:<br>
> Should the full version "1.2.3" be put into PROJECT_VERSION or<br>
> PROJECT_VERSION_STRING ?<br>
> Both forms are used in different places in cmake.<br>
<br>
I usually consider PROJECT_VERSION = Major.Minor.Patch and<br>
PROJECT_VERSION_STRING as a customizable string that can be assigned by<br>
the developer (i.e. PROJECT_VERSION "1.9.90" could be<br>
PROJECT_VERSION_STRING "2.0 Beta 1"), therefore I'd say PROJECT_VERSION<br>
<br>
<br>
Maybe the signature could even be<br>
<br>
  project(Foo VERSION 1.9.90 VERSION_STRING "2.0 Beta 1")<br>
<br>
with "VERSION_STRING" defaulting to "VERSION"<br>
<br>
<br>
<br>
Cheers,<br>
 Daniele<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 13 Jan 2014 09:34:20 -0500<br>
From: Brad King <<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>><br>
To: <a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a><br>
Subject: Re: [cmake-developers] RFC/Review Request: Topic<br>
        GNUInstallDirs_debian-multiarch-fix<br>
Message-ID: <<a href="mailto:52D3F96C.4090701@kitware.com">52D3F96C.4090701@kitware.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 01/13/2014 03:45 AM, Daniele E. Domenichelli wrote:<br>
> Please review the topic GNUInstallDirs_debian-multiarch-fix<br>
> GNUInstallDirs: Fix CMAKE_INSTALL_LIBDIR on Debian<br>
<br>
This looks like a good fix but some details need adjustment.<br>
<br>
This hunk:<br>
<br>
-if(NOT DEFINED CMAKE_INSTALL_LIBDIR)<br>
<br>
removes the guard that avoids doing all the default-computing<br>
logic when there is already a value.  In this hunk:<br>
<br>
+set(CMAKE_INSTALL_LIBDIR "${_LIBDIR_DEFAULT}" CACHE PATH "object code libraries (${_LIBDIR_DEFAULT})" FORCE)<br>
<br>
one should not FORCE the cache entry.  Otherwise there is no way<br>
for the local users to change the setting for their build trees.<br>
<br>
Both of the above are incorrect and seem unrelated to the proposed<br>
change.<br>
<br>
In this hunk:<br>
<br>
+    if (${CMAKE_INSTALL_PREFIX} MATCHES "^/usr/?$")<br>
<br>
the left side should be quoted or just the plain variable name<br>
to ensure it works when the prefix value is an empty string.<br>
<br>
Thanks,<br>
-Brad<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 13 Jan 2014 15:47:39 +0100<br>
From: "Daniele E. Domenichelli" <<a href="mailto:daniele.domenichelli@gmail.com">daniele.domenichelli@gmail.com</a>><br>
To: <a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a><br>
Subject: Re: [cmake-developers] RFC/Review Request: Topic<br>
        GNUInstallDirs_debian-multiarch-fix<br>
Message-ID: <<a href="mailto:52D3FC8B.9050208@gmail.com">52D3FC8B.9050208@gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 13/01/14 15:34, Brad King wrote:<br>
> This hunk:<br>
><br>
> -if(NOT DEFINED CMAKE_INSTALL_LIBDIR)<br>
><br>
> removes the guard that avoids doing all the default-computing<br>
> logic when there is already a value.  In this hunk:<br>
><br>
> +set(CMAKE_INSTALL_LIBDIR "${_LIBDIR_DEFAULT}" CACHE PATH "object code libraries (${_LIBDIR_DEFAULT})" FORCE)<br>
><br>
> one should not FORCE the cache entry.  Otherwise there is no way<br>
> for the local users to change the setting for their build trees.<br>
><br>
> Both of the above are incorrect and seem unrelated to the proposed<br>
> change.<br>
<br>
<br>
The problem comes when you change the CMAKE_INSTALL_PREFIX:<br>
<br>
When you run cmake (with no -DCMAKE_INSTALL_PREFIX=... argument),<br>
CMAKE_INSTALL_PREFIX is set to /usr/local, and the CMAKE_INSTALL_LIBDIR<br>
is set to lib.<br>
<br>
If later you want to change it to CMAKE_INSTALL_PREFIX to /usr, without<br>
the removing the if(), the code is not called, and without the "FORCE",<br>
the cached value is not updated.<br>
<br>
But I also just realized that the variable is "CACHE PATH" for some<br>
reason I thought it was "CACHE INTERNAL", that means that the user can<br>
change it, and therefore the force is not a good idea.<br>
<br>
How do you suggest to handle this?<br>
<br>
<br>
<br>
> In this hunk:<br>
><br>
> +    if (${CMAKE_INSTALL_PREFIX} MATCHES "^/usr/?$")<br>
><br>
> the left side should be quoted or just the plain variable name<br>
> to ensure it works when the prefix value is an empty string.<br>
<br>
Fixed in the topic.<br>
<br>
<br>
<br>
Thanks,<br>
 Daniele<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 13 Jan 2014 09:54:14 -0500<br>
From: Brad King <<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>><br>
To: Clinton Stimpson <<a href="mailto:clinton@elemtech.com">clinton@elemtech.com</a>><br>
Cc: <a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a><br>
Subject: [cmake-developers] Github pull request 81 for cmake-gui<br>
Message-ID: <<a href="mailto:52D3FE16.1060706@kitware.com">52D3FE16.1060706@kitware.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Clinton,<br>
<br>
Please take a look at this change:<br>
<br>
 <a href="https://github.com/Kitware/CMake/pull/81" target="_blank">https://github.com/Kitware/CMake/pull/81</a><br>
<br>
 git fetch <a href="https://github.com/sryze/CMake" target="_blank">https://github.com/sryze/CMake</a> var-type-autofill<br>
<br>
and integrate it if it makes sense.<br>
<br>
Thanks,<br>
-Brad<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Mon, 13 Jan 2014 09:57:07 -0500<br>
From: Brad King <<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>><br>
To: <a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a><br>
Subject: Re: [cmake-developers] RFC/Review Request: Topic<br>
        GNUInstallDirs_debian-multiarch-fix<br>
Message-ID: <<a href="mailto:52D3FEC3.2060008@kitware.com">52D3FEC3.2060008@kitware.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 01/13/2014 09:47 AM, Daniele E. Domenichelli wrote:<br>
> The problem comes when you change the CMAKE_INSTALL_PREFIX:<br>
><br>
> When you run cmake (with no -DCMAKE_INSTALL_PREFIX=... argument),<br>
> CMAKE_INSTALL_PREFIX is set to /usr/local, and the CMAKE_INSTALL_LIBDIR<br>
> is set to lib.<br>
><br>
> If later you want to change it to CMAKE_INSTALL_PREFIX to /usr, without<br>
> the removing the if(), the code is not called, and without the "FORCE",<br>
> the cached value is not updated.<br>
<br>
Store an empty string in the cache but with help text that says<br>
what the default will be.  When the cached value is set to non-empty<br>
then use it because we know the user must have set it to something.<br>
Otherwise compute the default and set it as a normal variable.<br>
<br>
-Brad<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Mon, 13 Jan 2014 16:23:15 +0100<br>
From: "Daniele E. Domenichelli" <<a href="mailto:daniele.domenichelli@gmail.com">daniele.domenichelli@gmail.com</a>><br>
To: <a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a><br>
Subject: Re: [cmake-developers] RFC/Review Request: Topic<br>
        GNUInstallDirs_debian-multiarch-fix<br>
Message-ID: <<a href="mailto:52D404E3.6000601@gmail.com">52D404E3.6000601@gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 13/01/14 15:57, Brad King wrote:<br>
> On 01/13/2014 09:47 AM, Daniele E. Domenichelli wrote:<br>
>> The problem comes when you change the CMAKE_INSTALL_PREFIX:<br>
>><br>
>> When you run cmake (with no -DCMAKE_INSTALL_PREFIX=... argument),<br>
>> CMAKE_INSTALL_PREFIX is set to /usr/local, and the CMAKE_INSTALL_LIBDIR<br>
>> is set to lib.<br>
>><br>
>> If later you want to change it to CMAKE_INSTALL_PREFIX to /usr, without<br>
>> the removing the if(), the code is not called, and without the "FORCE",<br>
>> the cached value is not updated.<br>
><br>
> Store an empty string in the cache but with help text that says<br>
> what the default will be.  When the cached value is set to non-empty<br>
> then use it because we know the user must have set it to something.<br>
> Otherwise compute the default and set it as a normal variable.<br>
<br>
But if the file is not included in the top directory, then the variable<br>
will not be set for other sub-directories, and I think that this might<br>
be considered a change of behaviour, and might break some builds.<br>
<br>
Can I store CMAKE_INSTALL_PREFIX in an internal cached variable, check<br>
if it was changed since last run (i.e. CMAKE_INSTALL_PREFIX_OLD !=<br>
CMAKE_INSTALL_PREFIX), check if the value is the default one, and<br>
eventually force-set it to the new default?<br>
<br>
<br>
Daniele<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
cmake-developers mailing list<br>
<a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a><br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers</a><br>
<br>
<br>
------------------------------<br>
<br>
End of cmake-developers Digest, Vol 66, Issue 19<br>
************************************************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><br><table cellspacing="0" cellpadding="0" style="font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Vince Harron |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Technical Lead Manager |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:vharron@google.com" target="_blank">vharron@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px">
 858-442-0868</td></tr></tbody></table><br></div>
</div></div></div>