* [Buildroot] moving package divine from autotools-package to generic-package
@ 2013-03-08 21:08 Carsten Schoenert
2013-03-09 9:13 ` Thomas Petazzoni
0 siblings, 1 reply; 4+ messages in thread
From: Carsten Schoenert @ 2013-03-08 21:08 UTC (permalink / raw)
To: buildroot
Hello,
we want to try ilixi [1] on a SetTopBox.
To be able to use it I have to solve the dependency on directfb 1.6.3,
that was not a big problem. So for now I'm not knowing if we can use the
input driver for raw input via a virtual input device that's provided by
DiVine [2]. So thought I bumping the package also to 1.6.3, that was
also easy.
But, the archive on directfb.org is broken, inside the archive in the
lib/ directory the Header idivine.h is missing. Inside the Git Repo
everything is fine. I wrote up the maintainer and describe the issue but
until now no response from there.
So I tried to change package divine from a autotools-package to a
generic package because the Git Repo just shipped a file autogen.sh for
package preparation.
The build works so far but I'm not very familiar with the voodoo of the
generic-package mechanism. So I want to ask if you can please take a
look at my work before go further and prepare a patch.
This is the file package/divine/divine.mk looks like now.
> #############################################################
> #
> # divine
> #
> #############################################################
>
> # tagged version 1.6.3
> DIVINE_VERSION = 83cafc257a42b9465cd9d6185bf66b8c1b7ed704
> DIVINE_SITE = git://git.directfb.org/git/directfb/extras/DiVine.git
> DIVINE_LICENSE = LGPLv2.1+
> DIVINE_LICENSE_FILE = COPYING
> DIVINE_INSTALL_STAGING = YES
> DIVINE_DEPENDENCIES = directfb
> DIVINE_CONFIG_SCRIPTS = divine-config
>
> DIVINE_CONF_OPTS = $(TARGET_CONFIGURE_OPTS) \
> $(TARGET_CONFIGURE_ARGS) \
> --target=$(GNU_TARGET_NAME) \
> --host=$(GNU_TARGET_NAME) \
> --prefix="$(HOST_DIR)/usr"
>
> define DIVINE_CONFIGURE_CMDS
> (cd $(@D) && \
> ACLOCAL_FLAGS="-I $(ACLOCAL_DIR)" \
> PKG_CONFIG_PATH="$(STAGING_DIR)/usr/lib/pkgconfig" \
> ./autogen.sh $(DIVINE_CONF_OPTS))
> endef
>
> define DIVINE_BUILD_CMDS
> $(MAKE) -C $(@D)
> endef
>
> define DIVINE_INSTALL_STAGING_CMDS
> DESTDIR=$(STAGING_DIR)/usr $(MAKE) -C $(@D) install
> endef
>
> define DIVINE_INSTALL_TARGET_CMDS
> DESTDIR=$(TARGET_DIR)/usr $(MAKE) -C $(@D) install
> endef
>
> $(eval $(generic-package))
> $(eval $(host-generic-package))
I think the --prefix option can be left, the destdir is given by the
install commands.
Are the directory all correct or is there something more improvable?
The call of the two macros at the end is needed as far as I understand.
I tested the build only for my ARM based SetTopBox, maybe other
platforms need enhancements.
Thanks for feedback!
Regards
Carsten
[1] http://www.ilixi.org/
[2] http://directfb.org/downloads/Extras/README.DiVine
^ permalink raw reply [flat|nested] 4+ messages in thread* [Buildroot] moving package divine from autotools-package to generic-package 2013-03-08 21:08 [Buildroot] moving package divine from autotools-package to generic-package Carsten Schoenert @ 2013-03-09 9:13 ` Thomas Petazzoni 2013-03-10 8:59 ` Carsten Schoenert 0 siblings, 1 reply; 4+ messages in thread From: Thomas Petazzoni @ 2013-03-09 9:13 UTC (permalink / raw) To: buildroot Dear Carsten Schoenert, On Fri, 08 Mar 2013 22:08:48 +0100, Carsten Schoenert wrote: > But, the archive on directfb.org is broken, inside the archive in the > lib/ directory the Header idivine.h is missing. Inside the Git Repo > everything is fine. I wrote up the maintainer and describe the issue but > until now no response from there. > So I tried to change package divine from a autotools-package to a > generic package because the Git Repo just shipped a file autogen.sh for > package preparation. No, no, it should continue to be an autotools-package. It has a configure.in, and Makefile.am, it is autotools based, so it should remain an autotools-package. Now, since you're getting it from git instead of a tarball, the configure script and Makefile.in are not pre-generated, so we have to get them generated. Can you just try to do: DIVINE_AUTORECONF = YES in the package recipe? Looking at what the autogen.sh script does, I think our autoreconf logic should work. Otherwise, we will just add a hook in the package recipe in order to call autogen. But clearly, converting to generic-package is the wrong way to go. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Buildroot] moving package divine from autotools-package to generic-package 2013-03-09 9:13 ` Thomas Petazzoni @ 2013-03-10 8:59 ` Carsten Schoenert 2013-03-10 9:27 ` Thomas Petazzoni 0 siblings, 1 reply; 4+ messages in thread From: Carsten Schoenert @ 2013-03-10 8:59 UTC (permalink / raw) To: buildroot Hello Thomas, Am 09.03.2013 10:13, schrieb Thomas Petazzoni: > No, no, it should continue to be an autotools-package. It has a > configure.in, and Makefile.am, it is autotools based, so it should > remain an autotools-package. O.K. In short, if a package is comprised a file 'autogen.sh' and this generate the whole autotool stuff the package has to be a autotools-package. > Now, since you're getting it from git instead of a tarball, the > configure script and Makefile.in are not pre-generated, so we have to > get them generated. > > Can you just try to do: > > DIVINE_AUTORECONF = YES > > in the package recipe? Yes this works, but I get some warnings! Maybe the AUTORECONF things has to be a little reworked. I don't know there to look to solve thees warnings. The package divine doesn't have a macro AC_LANG_CONFTEST in use. > carsten at wheezy:~/gitprojects/buildroot [ubi-arm-directfb] $ make divine-dirclean > rm -Rf /home/carsten/gitprojects/buildroot/output/build/divine-83cafc257a42b9465cd9d6185bf66b8c1b7ed704 > carsten at wheezy:~/gitprojects/buildroot [ubi-arm-directfb] $ make divine >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Extracting > gzip -d -c /home/carsten/gitprojects/buildroot/dl/divine-83cafc257a42b9465cd9d6185bf66b8c1b7ed704.tar.gz | tar --strip-components=1 -C /home/carsten/gitprojects/buildroot/output/build/divine-83cafc257a42b9465cd9d6185bf66b8c1b7ed704 -xf - >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Patching package//divine >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Updating config.sub and config.guess > for file in config.guess config.sub; do for i in $(find /home/carsten/gitprojects/buildroot/output/build/divine-83cafc257a42b9465cd9d6185bf66b8c1b7ed704 -name $file); do cp support/gnuconfig/$file $i; done; done >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Patching libtool >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Autoreconfiguring > configure.in:56: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body > ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... > ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:1084: _LT_SYS_MODULE_PATH_AIX is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:4207: _LT_LINKER_SHLIBS is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:5339: _LT_LANG_C_CONFIG is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:143: _LT_SETUP is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:69: LT_INIT is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:108: AM_PROG_LIBTOOL is expanded from... > configure.in:56: the top level > configure.in:56: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body > ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... > ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:4207: _LT_LINKER_SHLIBS is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:5339: _LT_LANG_C_CONFIG is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:143: _LT_SETUP is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:69: LT_INIT is expanded from... > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:108: AM_PROG_LIBTOOL is expanded from... > configure.in:56: the top level > configure.in:56: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body > ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... > ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... > ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ... At the end the output is installed to the target directory. > But clearly, converting to generic-package is the wrong way to go. I understand, maybe this can be more precise highlighted in the manual. So now I will rework my work to prepare some patches. Thanks for reviewing! Regards Carsten ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Buildroot] moving package divine from autotools-package to generic-package 2013-03-10 8:59 ` Carsten Schoenert @ 2013-03-10 9:27 ` Thomas Petazzoni 0 siblings, 0 replies; 4+ messages in thread From: Thomas Petazzoni @ 2013-03-10 9:27 UTC (permalink / raw) To: buildroot Dear Carsten Schoenert, On Sun, 10 Mar 2013 09:59:51 +0100, Carsten Schoenert wrote: > Am 09.03.2013 10:13, schrieb Thomas Petazzoni: > > No, no, it should continue to be an autotools-package. It has a > > configure.in, and Makefile.am, it is autotools based, so it should > > remain an autotools-package. > > O.K. In short, if a package is comprised a file 'autogen.sh' and this > generate the whole autotool stuff the package has to be a autotools-package. Yes, unless there are some specific issues, all packages that use autoconf/automake should use the autotools-package infrastructure. > Yes this works, but I get some warnings! Maybe the AUTORECONF things has > to be a little reworked. I don't know there to look to solve thees > warnings. The package divine doesn't have a macro AC_LANG_CONFTEST in use. > > carsten at wheezy:~/gitprojects/buildroot [ubi-arm-directfb] $ make divine-dirclean > > rm -Rf /home/carsten/gitprojects/buildroot/output/build/divine-83cafc257a42b9465cd9d6185bf66b8c1b7ed704 > > carsten at wheezy:~/gitprojects/buildroot [ubi-arm-directfb] $ make divine > >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Extracting > > gzip -d -c /home/carsten/gitprojects/buildroot/dl/divine-83cafc257a42b9465cd9d6185bf66b8c1b7ed704.tar.gz | tar --strip-components=1 -C /home/carsten/gitprojects/buildroot/output/build/divine-83cafc257a42b9465cd9d6185bf66b8c1b7ed704 -xf - > >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Patching package//divine > >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Updating config.sub and config.guess > > for file in config.guess config.sub; do for i in $(find /home/carsten/gitprojects/buildroot/output/build/divine-83cafc257a42b9465cd9d6185bf66b8c1b7ed704 -name $file); do cp support/gnuconfig/$file $i; done; done > >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Patching libtool > >>>> divine 83cafc257a42b9465cd9d6185bf66b8c1b7ed704 Autoreconfiguring > > configure.in:56: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body > > ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... > > ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... > > ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:1084: _LT_SYS_MODULE_PATH_AIX is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:4207: _LT_LINKER_SHLIBS is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:5339: _LT_LANG_C_CONFIG is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:143: _LT_SETUP is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:69: LT_INIT is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:108: AM_PROG_LIBTOOL is expanded from... > > configure.in:56: the top level > > configure.in:56: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body > > ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... > > ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... > > ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:4207: _LT_LINKER_SHLIBS is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:5339: _LT_LANG_C_CONFIG is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:143: _LT_SETUP is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:69: LT_INIT is expanded from... > > /home/carsten/gitprojects/buildroot/output/host/usr/share/aclocal/libtool.m4:108: AM_PROG_LIBTOOL is expanded from... > > configure.in:56: the top level > > configure.in:56: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body > > ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... > > ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... > > ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... > ... Yes. I am not an expert in autoconf/automake, but there are often some warnings due to slight changes in the autoconf/automake languages, and the corresponding configure.ac/Makefile.am in the project not being updated accordingly. > > But clearly, converting to generic-package is the wrong way to go. > > I understand, maybe this can be more precise highlighted in the manual. Hum, ok. About the generic-package infrastructure, the manual says: By packages with specific build systems we mean all the packages whose build system is not one of the standard ones, such as autotools or CMake. This typically includes packages whose build system is based on hand-written Makefiles or shell scripts. Maybe this wording is not explicit enough? > So now I will rework my work to prepare some patches. Thanks for reviewing! You're welcome, thanks for contributing! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-03-10 9:27 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-08 21:08 [Buildroot] moving package divine from autotools-package to generic-package Carsten Schoenert 2013-03-09 9:13 ` Thomas Petazzoni 2013-03-10 8:59 ` Carsten Schoenert 2013-03-10 9:27 ` Thomas Petazzoni
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox