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