Re: [Buildroot] [PATCH 1/1] package/re2: switch to generic-package make build

["Yann E. MORIN" <yann.morin.1998@free.fr>]

James, All,

On 2022-01-20 16:57 -0700, James Hilliard spake thusly:
> On Thu, Jan 20, 2022 at 2:29 PM Peter Seiderer <ps.report@gmx.net> wrote:
> > Or keep the cmake build and do the following to install re2.pc (taken from #349, [1]):
> >
> > --- a/package/re2/re2.mk
> > +++ b/package/re2/re2.mk
> > @@ -9,9 +9,20 @@ RE2_SITE = $(call github,google,re2,$(RE2_VERSION))
> >  RE2_LICENSE = BSD-3-Clause
> >  RE2_LICENSE_FILES = LICENSE
> >  RE2_INSTALL_STAGING = YES
> > +# keep original Makefile (for re2.pc install)
> > +RE2_SUPPORTS_IN_SOURCE_BUILD = NO
> >
> >  RE2_CONF_OPTS += -DRE2_BUILD_TESTING=OFF
> >  HOST_RE2_CONF_OPTS += -DRE2_BUILD_TESTING=OFF -DBUILD_SHARED_LIBS=ON
> >
> > +# install re2.pc
> > +define RE2_INSTALL_PKG_CONFIG
> > +       $(MAKE1) -C $(@D) DESTDIR=$(STAGING_DIR) \
> > +               libdir=/usr/lib includedir=/usr/include \
> > +               common-install
> > +endef
> > +
> > +RE2_POST_INSTALL_STAGING_HOOKS += RE2_INSTALL_PKG_CONFIG
> > +
> >  $(eval $(cmake-package))
> >  $(eval $(host-cmake-package))
> >
> > Regards,
> > Peter
> >
> > [1] https://github.com/macports/macports-ports/pull/9836#issuecomment-807868854
> 
> There's a problem with this approach, the makefile with common-install
> gets overwritten
> by the one generated by cmake if cmake is used.

It currently gets overwritten, because the build is done in-tree, but
What Peter suggests is doing the build out-of-tree, with:
    RE2_SUPPORTS_IN_SOURCE_BUILD = NO

However, I can't say that I am very fond of this option either. Misinx
the two buildsystems looks icky... What bothers me a bit, is that
common-install also installs the headers, not just the re2.pc, so this
could, even if unlikely, conflict with what the cmake-side would do.

But when looking at the various bugs about this issue:

    https://github.com/google/re2/issues/349
     -> https://github.com/google/re2/issues/304#issuecomment-808219200
         -> https://github.com/macports/macports-ports/pull/9836

    re2: change to cmake build to support gprc, which currently needs a
    cmake version of re2 to build. Try to make it work like the previous
    autotools build worked.

So, that last issue, against homebrew, is interesting: it seems that
using the Makefile-based buildsystem is not enough, because it does not
isntall the cmake equivalent of re2.pc, which breaks grpc.

So, whether we keep the cmake build, or switch to the Makefile build, we
would eventually still miss some pieces...

Damn, back to square-one...

So, I think that Peter's proposal is not so un-appealing, in then end.
But then in such situation, I think it would be simpler for us to just
apply something like:

    define RE2_INSTALL_PC
        $(INTALL) -d -m 0644 $(@D)/re2.pc \
            $(STAGING_DIR)/usr/lib/pkgconfig/re2.pc
        $(SED) 's,@includedir@,/usr/include,; s,@libdir@,/usr/lib,' \
            $(STAGING_DIR)/usr/lib/pkgconfig/re2.pc
    endef
    RE2_POST_STAGING_INSTALL_HOOKS += RE2_INSTALL_PC

And be done with it: minimal change to the re2 package, no dual-buildsystem
situation and thus no install conflict on the headers, usual and simple
post-install hook.

Thoughts?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot