From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id BFFD21F803 for ; Tue, 8 Jan 2019 01:46:40 +0000 (UTC) Received: from localhost ([127.0.0.1]:41462 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gggTX-0007D7-7B for normalperson@yhbt.net; Mon, 07 Jan 2019 20:46:39 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gggTR-0007A9-0m for bug-gnulib@gnu.org; Mon, 07 Jan 2019 20:46:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gggTP-0001F1-1D for bug-gnulib@gnu.org; Mon, 07 Jan 2019 20:46:32 -0500 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:39126) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gggTM-0001Bo-Hz for bug-gnulib@gnu.org; Mon, 07 Jan 2019 20:46:29 -0500 Received: by mail-wm1-x32b.google.com with SMTP id f81so2686892wmd.4 for ; Mon, 07 Jan 2019 17:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z7WHIV9+o03QpLZ+Iy/F74SfUyTz5z3tuqZK1+dENtU=; b=fsSu9RhJE0OA/DYmNIq28kPUrUAgoz93dXDJu0CrN6OM0+foDLLg792fqIEdZiW/oV YGo0OZXdi+6LYpSZ7YVZzfK61eNo1logrJWyj8uAha/spUnn+AEHX4f28D1BauUA48UF sQV6cH3Ju3muutfiyEIC+YWOYSUh7LtE9K1+MQyYiA4KbnMz/eWyNsbrWI9sS8mtM/Ax Fp6Lm5chfjklB21pymHDmVJYiN++jqJJ+aQoEyHmIJ3iBMjWiPw6Ox5ogrrRWr7QGJ6t xjxBuWN5OvEKTW93f60YQhABz4UNOytFtmXk7kYPHxd6sY7SyhpGYtThSGgZR+dqK/Fo 1qIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z7WHIV9+o03QpLZ+Iy/F74SfUyTz5z3tuqZK1+dENtU=; b=C1kKeYv59/rDHLdCk9NTYTsUoEnSrwflonKrxHQZ+qSZsZBeN4QBzbOd8Gq5+AeILP ASpBwjmLwgjbCymhCJGlPo/6pdi/Et0hDjZM0GQonEuCcSgCt3McrtoVkIC/8X23Yy1d MkPBX+8q/ECsXLw4Nyzs3g9HpUutg+XcZ0DrqtcbnhpOLaEKycLnr91j+xwlKm8jL8FW 579Etb2K9E6cCzF4NfC0cNamP/PT6VR9H8rp7VuFDq79av6vn6ymK7ggpM55iaAYlaVz kssvsCja0xTi5gz+dTtO1pkWl7ZdYM5fQp741n3lwYKjlQyhuBMA++zGtSldC+Q/zq8y 8HUA== X-Gm-Message-State: AJcUukfVj6dabDOVaKHHw9aW4fgyFyWCPJG0MmZV96AvyJ7yX5DuDDg7 +fksijb8xgqp1Jz7TCbiaE4yqFCFnOg13vpGtgD3l3zB X-Google-Smtp-Source: ALg8bN492V3W1KgK0WddNNGOuh1j83xoZWJw/5+fMw8SOc9CfOsHGA6XceUsliZ3z/95w+3txHUP5m7yaUQoP5911yw= X-Received: by 2002:a1c:c181:: with SMTP id r123mr157903wmf.8.1546911979898; Mon, 07 Jan 2019 17:46:19 -0800 (PST) MIME-Version: 1.0 References: <4708743.mAexus13G1@kdudka-nb> <6589477.oZLneipaSj@kdudka-nb> In-Reply-To: <6589477.oZLneipaSj@kdudka-nb> From: Andrew Pennebaker Date: Mon, 7 Jan 2019 19:46:08 -0600 Message-ID: Subject: Re: cmake support To: Kamil Dudka Content-Type: multipart/alternative; boundary="0000000000000f8b7e057ee8833c" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::32b X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bruno Haible , bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" --0000000000000f8b7e057ee8833c Content-Type: text/plain; charset="UTF-8" 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 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 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 --0000000000000f8b7e057ee8833c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm, cmake clearly suppo= rts building *libraries and executables* for non-cmake external projects. B= ut in the case of gnulib, gnulib itself does not emit a library or executab= le, 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 m= y project's build system in terms of autotools?

Specifically, could someone clarify how gl_EA= RLY is supposed to be triggerd by cmake in the inner gnulib project, so tha= t files like openat.h can be sourced from the cmake outer project? I don= 9;t know enough about autoconf yet to understand how cmake would do this. I= t'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")
=C2=A0 ExternalProject_Add(
=C2=A0=C2=A0=C2=A0 gnu= lib
=C2=A0=C2=A0=C2=A0 SOURCE_DIR "gnulib"
=C2=A0=C2=A0=C2= =A0 CONFIGURE_COMMAND "${PROJECT_SOURCE_DIR}/gnulib/gnulib-tool" = --dir "${PROJECT_SOURCE_DIR}/gnulib-prefix/src/gnulib-build" --im= port openat # && autoreconf -i && ./configure
=C2=A0=C2= =A0=C2=A0 BUILD_COMMAND echo
=C2=A0=C2=A0=C2=A0 INSTALL_COMMAND echo
= =C2=A0 )
=C2=A0 add_dependencies(fewer gnulib)
=C2=A0 target_include_= directories(fewer PUBLIC gnulib-prefix/src/gnulib-build/lib)
=C2=A0 targ= et_link_libraries(fewer libgnu)
endif()

On Sun, Jan 6, 2019 at 3:37 AM Kamil D= udka <kdudka@redhat.com> wro= te:
On Sunday, J= anuary 6, 2019 3:22:01 AM CET Andrew Pennebaker wrote:
> Ach, I've made a career out of not having to know autotools! ./con= figure &&
> make && [sudo] make install were black boxes as far as I was c= oncerned.
>
> 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 ca= n
> disable Gnulib for targets that don't actually need it. This is wh= at 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<= br> change because gnulib's developers do not want gnulib to be used this w= ay:

https://www.gnu.org/software/gnulib/manual/html_node/Library-vs-Reus= able-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 particula= r, 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 gen= erate cmake
> > > configurations.
> > >
> > >=C2=A0 =C2=A01. Because the GNU build system is based on Auto= tools.
> > >=C2=A0 =C2=A02. Because many people say that cmake is a horro= r to use. [1][2]
> >
> > That is not an argument.=C2=A0 You can find similar horror storie= s about
> >
> > autotools:
> >=C2=A0 =C2=A0 =C2=A0http://= voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
> > >
> > > But gnulib-tool by design creates a subdirectory, and you ca= n yourself
> > >
> > >=C2=A0 =C2=A0- add a simple configure.ac to that subdirectory, = as outlined in the
> > >=C2=A0 =C2=A0
> > >=C2=A0 =C2=A0 =C2=A0documentation [3],
> >
> > When I needed it 10 years ago, I was able to get around this limi= tation by
> > using the --create-testdir option of gnulib-tool.=C2=A0 It create= d 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
> >
> > >=C2=A0 =C2=A0- integrate this subdirectory with cmake through= an 'ExternalProject'
> >
> > [4].
> >
> > > If, during this process, you encounter pain points that requ= ire (small)
> > > gnulib-tool changes, please come back to us and report them.=
> > >
> > > Bruno
> > >
> > > [1]
> >
> > https://www.redd= it.com/r/cpp/comments/4flb8z/fighting_through_a_cmake_hell
> > /
> >
> > > [2]
> > > https://www.r= eddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/
> > > [3]
> > > https://www.g= nu.org/software/gnulib/manual/html_node/Initial-import.html
> > > [4]
> >
> > https://stackove= rflow.com/questions/5971921/building-a-library-using-autot
> > o
> >
> > > ols-from-cmake




--
Cheers,
Andrew
--0000000000000f8b7e057ee8833c--