[cmake-developers] [Generator] Android.mk

Wed Feb 26 17:21:39 EST 2014

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-request at cmake.org> wrote:

> Message-ID: <lb0kh6$mhf$1 at ger.gmane.org>
>
> Eric Wing wrote:
>
> > On 1/10/14, Stephen Kelly
> > <steveire at 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.domenichelli at gmail.com>
> To: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] RFC: add version to project() call
> Message-ID: <52D3DDB3.5010709 at 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.king at kitware.com>
> To: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] RFC/Review Request: Topic
>         GNUInstallDirs_debian-multiarch-fix
> Message-ID: <52D3F96C.4090701 at 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.domenichelli at gmail.com>
> To: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] RFC/Review Request: Topic
>         GNUInstallDirs_debian-multiarch-fix
> Message-ID: <52D3FC8B.9050208 at 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.king at kitware.com>
> To: Clinton Stimpson <clinton at elemtech.com>
> Cc: cmake-developers at cmake.org
> Subject: [cmake-developers] Github pull request 81 for cmake-gui
> Message-ID: <52D3FE16.1060706 at 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.king at kitware.com>
> To: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] RFC/Review Request: Topic
>         GNUInstallDirs_debian-multiarch-fix
> Message-ID: <52D3FEC3.2060008 at 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.domenichelli at gmail.com>
> To: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] RFC/Review Request: Topic
>         GNUInstallDirs_debian-multiarch-fix
> Message-ID: <52D404E3.6000601 at 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 at 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 | vharron at google.com | 858-442-0868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140226/d9200646/attachment-0001.html>