cmake support

cmake support

[Andrew Pennebaker]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

Could we improve how gnulib integrates with downstream projects, to make it
easier to work with different build tools? In particular, would be helpful
for gnulib to easily work with cmake projects.

In my case, I have an application that needs openat(), and I already have a
complex cmake configuration that would be difficult to rewrite in terms of
autotools.

-- 
Cheers,
Andrew

[-- Attachment #2: Type: text/html, Size: 589 bytes --]

Re: cmake support

[Paul Eggert]

Andrew Pennebaker wrote:
> Could we improve how gnulib integrates with downstream projects, to make it
> easier to work with different build tools? In particular, would be helpful
> for gnulib to easily work with cmake projects.

It would also be helpful for Gnulib to work better with GNU Make, while we're 
thinking about what to add to our to-do list. (I contributed some changes in 
that area, but I'm sure more improvements would be helpful.) The problem here 
mainly is a shortage of volunteers to do the work.

Re: cmake support

[Bruno Haible]

Hi,

Andrew Pennebaker wrote:
> Could we improve how gnulib integrates with downstream projects, to make it
> easier to work with different build tools? In particular, would be helpful
> for gnulib to easily work with cmake projects.
> 
> In my case, I have an application that needs openat(), and I already have a
> complex cmake configuration that would be difficult to rewrite in terms of
> autotools.

I don't think we will spend time to make gnulib-tool generate cmake
configurations.
  1. Because the GNU build system is based on Autotools.
  2. Because many people say that cmake is a horror to use. [1][2]

But gnulib-tool by design creates a subdirectory, and you can yourself
  - add a simple configure.ac to that subdirectory, as outlined in the
    documentation [3],
  - integrate this subdirectory with cmake through an 'ExternalProject' [4].

If, during this process, you encounter pain points that require (small)
gnulib-tool changes, please come back to us and report them.

Bruno

[1] https://www.reddit.com/r/cpp/comments/4flb8z/fighting_through_a_cmake_hell/
[2] https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/
[3] https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html
[4] https://stackoverflow.com/questions/5971921/building-a-library-using-autotools-from-cmake

Re: cmake support

[Kamil Dudka]

On Saturday, January 5, 2019 6:53:06 PM CET Bruno Haible wrote:
> Hi,
> 
> Andrew Pennebaker wrote:
> > Could we improve how gnulib integrates with downstream projects, to make
> > it
> > easier to work with different build tools? In particular, would be helpful
> > for gnulib to easily work with cmake projects.
> > 
> > In my case, I have an application that needs openat(), and I already have
> > a
> > complex cmake configuration that would be difficult to rewrite in terms of
> > autotools.
> 
> I don't think we will spend time to make gnulib-tool generate cmake
> configurations.
>   1. Because the GNU build system is based on Autotools.
>   2. Because many people say that cmake is a horror to use. [1][2]

That is not an argument.  You can find similar horror stories about autotools:

    http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/

> But gnulib-tool by design creates a subdirectory, and you can yourself
>   - add a simple configure.ac to that subdirectory, as outlined in the
>     documentation [3],

When I needed it 10 years ago, I was able to get around this limitation by 
using the --create-testdir option of gnulib-tool.  It created a directory
with configure script that (after running make) produced a static library.
I am not sure if this approach had any side effects, like turning on debug 
build, but I was at least not forced to create configure.ac etc.

Kamil

>   - integrate this subdirectory with cmake through an 'ExternalProject' [4].
> 
> If, during this process, you encounter pain points that require (small)
> gnulib-tool changes, please come back to us and report them.
> 
> Bruno
> 
> [1]
> https://www.reddit.com/r/cpp/comments/4flb8z/fighting_through_a_cmake_hell/
> [2]
> https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/
> [3]
> https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html
> [4]
> https://stackoverflow.com/questions/5971921/building-a-library-using-autoto
> ols-from-cmake

Re: cmake support

[Andrew Pennebaker]

[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]

Ach, I've made a career out of not having to know autotools! ./configure &&
make && [sudo] make install were black boxes as far as I was concerned.

So be it, I'll spend some time reading up this weekend and see how far I
get. MSVC integration will become more interesting, but I suppose I can
disable Gnulib for targets that don't actually need it. This is what I get
for dipping my toes in CloudABI and introducing dprintf(), openat() to my
projects :P

Would be nice to offer NetBSD-style packages for MINIX and SmartOS, in
order to make Gnulib easier to install to a standard include path like with
other development libraries.

On Sat, Jan 5, 2019 at 12:31 PM Kamil Dudka <kdudka@redhat.com> wrote:

> On Saturday, January 5, 2019 6:53:06 PM CET Bruno Haible wrote:
> > Hi,
> >
> > Andrew Pennebaker wrote:
> > > Could we improve how gnulib integrates with downstream projects, to
> make
> > > it
> > > easier to work with different build tools? In particular, would be
> helpful
> > > for gnulib to easily work with cmake projects.
> > >
> > > In my case, I have an application that needs openat(), and I already
> have
> > > a
> > > complex cmake configuration that would be difficult to rewrite in
> terms of
> > > autotools.
> >
> > I don't think we will spend time to make gnulib-tool generate cmake
> > configurations.
> >   1. Because the GNU build system is based on Autotools.
> >   2. Because many people say that cmake is a horror to use. [1][2]
>
> That is not an argument.  You can find similar horror stories about
> autotools:
>
>     http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
>
> > But gnulib-tool by design creates a subdirectory, and you can yourself
> >   - add a simple configure.ac to that subdirectory, as outlined in the
> >     documentation [3],
>
> When I needed it 10 years ago, I was able to get around this limitation by
> using the --create-testdir option of gnulib-tool.  It created a directory
> with configure script that (after running make) produced a static library.
> I am not sure if this approach had any side effects, like turning on debug
> build, but I was at least not forced to create configure.ac etc.
>
> Kamil
>
> >   - integrate this subdirectory with cmake through an 'ExternalProject'
> [4].
> >
> > If, during this process, you encounter pain points that require (small)
> > gnulib-tool changes, please come back to us and report them.
> >
> > Bruno
> >
> > [1]
> >
> https://www.reddit.com/r/cpp/comments/4flb8z/fighting_through_a_cmake_hell/
> > [2]
> > https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/
> > [3]
> > https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html
> > [4]
> >
> https://stackoverflow.com/questions/5971921/building-a-library-using-autoto
> > ols-from-cmake
>
>
>

-- 
Cheers,
Andrew

[-- Attachment #2: Type: text/html, Size: 4372 bytes --]

Re: cmake support

[Bruno Haible]

Andrew Pennebaker wrote:
> MSVC integration will become more interesting

The usual way to do MSVC builds of packages that use Autotools is to use
wrapper scripts 'ar-lib' and 'compile' that provide a Unix-y interface to
the MSVC compilers. See
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=INSTALL.windows
for how this gets used.

> Would be nice to offer NetBSD-style packages for MINIX and SmartOS, in
> order to make Gnulib easier to install to a standard include path like with
> other development libraries.

Is there no 'git' available for these operating systems? The usual way to
install Gnulib is through git. See also
https://www.gnu.org/software/gnulib/manual/html_node/Library-vs-Reusable-Code.html

Bruno

Re: cmake support

[Kamil Dudka]

On Sunday, January 6, 2019 3:22:01 AM CET Andrew Pennebaker wrote:
> Ach, I've made a career out of not having to know autotools! ./configure &&
> make && [sudo] make install were black boxes as far as I was concerned.
> 
> So be it, I'll spend some time reading up this weekend and see how far I
> get. MSVC integration will become more interesting, but I suppose I can
> disable Gnulib for targets that don't actually need it. This is what I get
> for dipping my toes in CloudABI and introducing dprintf(), openat() to my
> projects :P
> 
> Would be nice to offer NetBSD-style packages for MINIX and SmartOS, in
> order to make Gnulib easier to install to a standard include path like with
> other development libraries.

I am afraid that there is no OS distribution that would install Gnulib to
a standard include (and library) path and this is most likely not going to
change because gnulib's developers do not want gnulib to be used this way:

https://www.gnu.org/software/gnulib/manual/html_node/Library-vs-Reusable-Code.html#Library-vs-Reusable-Code

Kamil

> On Sat, Jan 5, 2019 at 12:31 PM Kamil Dudka <kdudka@redhat.com> wrote:
> > On Saturday, January 5, 2019 6:53:06 PM CET Bruno Haible wrote:
> > > Hi,
> > > 
> > > Andrew Pennebaker wrote:
> > > > Could we improve how gnulib integrates with downstream projects, to
> > 
> > make
> > 
> > > > it
> > > > easier to work with different build tools? In particular, would be
> > 
> > helpful
> > 
> > > > for gnulib to easily work with cmake projects.
> > > > 
> > > > In my case, I have an application that needs openat(), and I already
> > 
> > have
> > 
> > > > a
> > > > complex cmake configuration that would be difficult to rewrite in
> > 
> > terms of
> > 
> > > > autotools.
> > > 
> > > I don't think we will spend time to make gnulib-tool generate cmake
> > > configurations.
> > > 
> > >   1. Because the GNU build system is based on Autotools.
> > >   2. Because many people say that cmake is a horror to use. [1][2]
> > 
> > That is not an argument.  You can find similar horror stories about
> > 
> > autotools:
> >     http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
> > > 
> > > But gnulib-tool by design creates a subdirectory, and you can yourself
> > > 
> > >   - add a simple configure.ac to that subdirectory, as outlined in the
> > >   
> > >     documentation [3],
> > 
> > When I needed it 10 years ago, I was able to get around this limitation by
> > using the --create-testdir option of gnulib-tool.  It created a directory
> > with configure script that (after running make) produced a static library.
> > I am not sure if this approach had any side effects, like turning on debug
> > build, but I was at least not forced to create configure.ac etc.
> > 
> > Kamil
> > 
> > >   - integrate this subdirectory with cmake through an 'ExternalProject'
> > 
> > [4].
> > 
> > > If, during this process, you encounter pain points that require (small)
> > > gnulib-tool changes, please come back to us and report them.
> > > 
> > > Bruno
> > > 
> > > [1]
> > 
> > https://www.reddit.com/r/cpp/comments/4flb8z/fighting_through_a_cmake_hell
> > /
> > 
> > > [2]
> > > https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/
> > > [3]
> > > https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html
> > > [4]
> > 
> > https://stackoverflow.com/questions/5971921/building-a-library-using-autot
> > o
> > 
> > > ols-from-cmake

Re: cmake support

[Andrew Pennebaker]

[-- Attachment #1: Type: text/plain, Size: 4995 bytes --]

Hmm, cmake clearly supports building *libraries and executables* for
non-cmake external projects. But in the case of gnulib, gnulib itself does
not emit a library or executable, right? It's meant to be sourced inside of
another autotools project. Can cmake really be integrated around gnulib, or
am I forced to rewrite my project's build system in terms of autotools?

Specifically, could someone clarify how gl_EARLY is supposed to be triggerd
by cmake in the inner gnulib project, so that files like openat.h can be
sourced from the cmake outer project? I don't know enough about autoconf
yet to understand how cmake would do this. It's hard enough getting this
far:

# CMakeLists.txt
# Doesn't even work on my machine^TM

add_executable(fewer lib/main.c lib/fewer.c)

if(CMAKE_SYSTEM_NAME MATCHES "Minix")
  ExternalProject_Add(
    gnulib
    SOURCE_DIR "gnulib"
    CONFIGURE_COMMAND "${PROJECT_SOURCE_DIR}/gnulib/gnulib-tool" --dir
"${PROJECT_SOURCE_DIR}/gnulib-prefix/src/gnulib-build" --import openat # &&
autoreconf -i && ./configure
    BUILD_COMMAND echo
    INSTALL_COMMAND echo
  )
  add_dependencies(fewer gnulib)
  target_include_directories(fewer PUBLIC
gnulib-prefix/src/gnulib-build/lib)
  target_link_libraries(fewer libgnu)
endif()

On Sun, Jan 6, 2019 at 3:37 AM Kamil Dudka <kdudka@redhat.com> wrote:

> On Sunday, January 6, 2019 3:22:01 AM CET Andrew Pennebaker wrote:
> > Ach, I've made a career out of not having to know autotools! ./configure
> &&
> > make && [sudo] make install were black boxes as far as I was concerned.
> >
> > So be it, I'll spend some time reading up this weekend and see how far I
> > get. MSVC integration will become more interesting, but I suppose I can
> > disable Gnulib for targets that don't actually need it. This is what I
> get
> > for dipping my toes in CloudABI and introducing dprintf(), openat() to my
> > projects :P
> >
> > Would be nice to offer NetBSD-style packages for MINIX and SmartOS, in
> > order to make Gnulib easier to install to a standard include path like
> with
> > other development libraries.
>
> I am afraid that there is no OS distribution that would install Gnulib to
> a standard include (and library) path and this is most likely not going to
> change because gnulib's developers do not want gnulib to be used this way:
>
>
> https://www.gnu.org/software/gnulib/manual/html_node/Library-vs-Reusable-Code.html#Library-vs-Reusable-Code
>
> Kamil
>
> > On Sat, Jan 5, 2019 at 12:31 PM Kamil Dudka <kdudka@redhat.com> wrote:
> > > On Saturday, January 5, 2019 6:53:06 PM CET Bruno Haible wrote:
> > > > Hi,
> > > >
> > > > Andrew Pennebaker wrote:
> > > > > Could we improve how gnulib integrates with downstream projects, to
> > >
> > > make
> > >
> > > > > it
> > > > > easier to work with different build tools? In particular, would be
> > >
> > > helpful
> > >
> > > > > for gnulib to easily work with cmake projects.
> > > > >
> > > > > In my case, I have an application that needs openat(), and I
> already
> > >
> > > have
> > >
> > > > > a
> > > > > complex cmake configuration that would be difficult to rewrite in
> > >
> > > terms of
> > >
> > > > > autotools.
> > > >
> > > > I don't think we will spend time to make gnulib-tool generate cmake
> > > > configurations.
> > > >
> > > >   1. Because the GNU build system is based on Autotools.
> > > >   2. Because many people say that cmake is a horror to use. [1][2]
> > >
> > > That is not an argument.  You can find similar horror stories about
> > >
> > > autotools:
> > >     http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
> > > >
> > > > But gnulib-tool by design creates a subdirectory, and you can
> yourself
> > > >
> > > >   - add a simple configure.ac to that subdirectory, as outlined in
> the
> > > >
> > > >     documentation [3],
> > >
> > > When I needed it 10 years ago, I was able to get around this
> limitation by
> > > using the --create-testdir option of gnulib-tool.  It created a
> directory
> > > with configure script that (after running make) produced a static
> library.
> > > I am not sure if this approach had any side effects, like turning on
> debug
> > > build, but I was at least not forced to create configure.ac etc.
> > >
> > > Kamil
> > >
> > > >   - integrate this subdirectory with cmake through an
> 'ExternalProject'
> > >
> > > [4].
> > >
> > > > If, during this process, you encounter pain points that require
> (small)
> > > > gnulib-tool changes, please come back to us and report them.
> > > >
> > > > Bruno
> > > >
> > > > [1]
> > >
> > >
> https://www.reddit.com/r/cpp/comments/4flb8z/fighting_through_a_cmake_hell
> > > /
> > >
> > > > [2]
> > > >
> https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/
> > > > [3]
> > > >
> https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html
> > > > [4]
> > >
> > >
> https://stackoverflow.com/questions/5971921/building-a-library-using-autot
> > > o
> > >
> > > > ols-from-cmake
>
>
>

-- 
Cheers,
Andrew

[-- Attachment #2: Type: text/html, Size: 7651 bytes --]

Re: cmake support

[Kamil Dudka]

On Tuesday, January 8, 2019 2:46:08 AM CET Andrew Pennebaker wrote:
> Hmm, cmake clearly supports building *libraries and executables* for
> non-cmake external projects. But in the case of gnulib, gnulib itself does
> not emit a library or executable, right?

gnulib builds a static library.  I thought it was obvious from my first reply.

> It's meant to be sourced inside of another autotools project.

Yes but a workaround exists and I mentioned it in my first reply.  Did you
try it?

Kamil

> Can cmake really be integrated around gnulib, or
> am I forced to rewrite my project's build system in terms of autotools?
> 
> Specifically, could someone clarify how gl_EARLY is supposed to be triggerd
> by cmake in the inner gnulib project, so that files like openat.h can be
> sourced from the cmake outer project? I don't know enough about autoconf
> yet to understand how cmake would do this. It's hard enough getting this
> far:
> 
> # CMakeLists.txt
> # Doesn't even work on my machine^TM
> 
> add_executable(fewer lib/main.c lib/fewer.c)
> 
> if(CMAKE_SYSTEM_NAME MATCHES "Minix")
>   ExternalProject_Add(
>     gnulib
>     SOURCE_DIR "gnulib"
>     CONFIGURE_COMMAND "${PROJECT_SOURCE_DIR}/gnulib/gnulib-tool" --dir
> "${PROJECT_SOURCE_DIR}/gnulib-prefix/src/gnulib-build" --import openat # &&
> autoreconf -i && ./configure
>     BUILD_COMMAND echo
>     INSTALL_COMMAND echo
>   )
>   add_dependencies(fewer gnulib)
>   target_include_directories(fewer PUBLIC
> gnulib-prefix/src/gnulib-build/lib)
>   target_link_libraries(fewer libgnu)
> endif()
> 
> On Sun, Jan 6, 2019 at 3:37 AM Kamil Dudka <kdudka@redhat.com> wrote:
> > On Sunday, January 6, 2019 3:22:01 AM CET Andrew Pennebaker wrote:
> > > Ach, I've made a career out of not having to know autotools! ./configure
> > 
> > &&
> > 
> > > make && [sudo] make install were black boxes as far as I was concerned.
> > > 
> > > So be it, I'll spend some time reading up this weekend and see how far I
> > > get. MSVC integration will become more interesting, but I suppose I can
> > > disable Gnulib for targets that don't actually need it. This is what I
> > 
> > get
> > 
> > > for dipping my toes in CloudABI and introducing dprintf(), openat() to
> > > my
> > > projects :P
> > > 
> > > Would be nice to offer NetBSD-style packages for MINIX and SmartOS, in
> > > order to make Gnulib easier to install to a standard include path like
> > 
> > with
> > 
> > > other development libraries.
> > 
> > I am afraid that there is no OS distribution that would install Gnulib to
> > a standard include (and library) path and this is most likely not going to
> > change because gnulib's developers do not want gnulib to be used this way:
> > 
> > 
> > https://www.gnu.org/software/gnulib/manual/html_node/Library-vs-Reusable-C
> > ode.html#Library-vs-Reusable-Code
> > 
> > Kamil
> > 
> > > On Sat, Jan 5, 2019 at 12:31 PM Kamil Dudka <kdudka@redhat.com> wrote:
> > > > On Saturday, January 5, 2019 6:53:06 PM CET Bruno Haible wrote:
> > > > > Hi,
> > > > > 
> > > > > Andrew Pennebaker wrote:
> > > > > > Could we improve how gnulib integrates with downstream projects,
> > > > > > to
> > > > 
> > > > make
> > > > 
> > > > > > it
> > > > > > easier to work with different build tools? In particular, would be
> > > > 
> > > > helpful
> > > > 
> > > > > > for gnulib to easily work with cmake projects.
> > > > > > 
> > > > > > In my case, I have an application that needs openat(), and I
> > 
> > already
> > 
> > > > have
> > > > 
> > > > > > a
> > > > > > complex cmake configuration that would be difficult to rewrite in
> > > > 
> > > > terms of
> > > > 
> > > > > > autotools.
> > > > > 
> > > > > I don't think we will spend time to make gnulib-tool generate cmake
> > > > > configurations.
> > > > > 
> > > > >   1. Because the GNU build system is based on Autotools.
> > > > >   2. Because many people say that cmake is a horror to use. [1][2]
> > > > 
> > > > That is not an argument.  You can find similar horror stories about
> > > > 
> > > > autotools:
> > > >     http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
> > > > > 
> > > > > But gnulib-tool by design creates a subdirectory, and you can
> > 
> > yourself
> > 
> > > > >   - add a simple configure.ac to that subdirectory, as outlined in
> > 
> > the
> > 
> > > > >     documentation [3],
> > > > 
> > > > When I needed it 10 years ago, I was able to get around this
> > 
> > limitation by
> > 
> > > > using the --create-testdir option of gnulib-tool.  It created a
> > 
> > directory
> > 
> > > > with configure script that (after running make) produced a static
> > 
> > library.
> > 
> > > > I am not sure if this approach had any side effects, like turning on
> > 
> > debug
> > 
> > > > build, but I was at least not forced to create configure.ac etc.
> > > > 
> > > > Kamil
> > > > 
> > > > >   - integrate this subdirectory with cmake through an
> > 
> > 'ExternalProject'
> > 
> > > > [4].
> > > > 
> > > > > If, during this process, you encounter pain points that require
> > 
> > (small)
> > 
> > > > > gnulib-tool changes, please come back to us and report them.
> > > > > 
> > > > > Bruno
> > > > > 
> > > > > [1]
> > 
> > https://www.reddit.com/r/cpp/comments/4flb8z/fighting_through_a_cmake_hell
> > 
> > > > /
> > > > 
> > > > > [2]
> > 
> > https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/
> > 
> > > > > [3]
> > 
> > https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html
> > 
> > > > > [4]
> > 
> > https://stackoverflow.com/questions/5971921/building-a-library-using-autot
> > 
> > > > o
> > > > 
> > > > > ols-from-cmake

Re: cmake support

[Bruno Haible]

Andrew Pennebaker wrote:
>     CONFIGURE_COMMAND "${PROJECT_SOURCE_DIR}/gnulib/gnulib-tool" --dir
> "${PROJECT_SOURCE_DIR}/gnulib-prefix/src/gnulib-build" --import openat # &&
> autoreconf -i && ./configure

I don't know if you intend to make releases with tarballs from your
project. But if so, the gnulib-tool and autoreconf steps need to be
invoked _before_ generation of the tarball (on the maintainer's machine),
and the configure step needs to be invoked _after_ unpacking the tarball
(on the target machine).

Bruno