wiringpi: new package

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Lucas" == Lucas De Marchi <[email protected]> writes:

psplash doesn't see a new release for quite some time. The lattest commits brought some nice bug fixes and a feature that allows to easily customize the splash image.

Signed-off-by Lucas De Marchi <[email protected]>

---
 package/psplash/psplash.mk | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

package/psplash/psplash.mk +0 -0

index cb1c54a..fe14f44 100644

Add pi4j using its released binaries. The java archives are a bit different than other packages. Since they are coming already pre-compiled put them in /opt with the same layout as in raspbian, according to http://pi4j.com/install.html

Dear Lucas De Marchi,

On Fri, 10 Jan 2014 17:50:22 -0200, Lucas De Marchi wrote:

Quoted 4 lines

Add pi4j using its released binaries. The java archives are a bit different than other packages. Since they are coming already pre-compiled put them in /opt with the same layout as in raspbian, according to http://pi4j.com/install.html

I think this is quite certainly the first Java library for which we have a package. Which JVM are you using to run this on the target? The official Oracle JDK?

I think this package, like Python/Lua/Perl packages, should depend on the selection of a JVM, be it the official Oracle JDK (for which a package would have to be created), or JamVM, if this package is actually compatible with it.

Regarding the installation in /opt, I'm not sure. The fact that Raspbian installs it here is not that much of an argument to me (quite the opposite, actually!).

On Ubuntu, the Java libraries are apparently installed in /usr/share/java/, which seems a bit more sensible to me. The JNI parts are installed in /usr/lib/jni/. See:

$ dpkg -L librxtx-java
[... skip documentation ...]
/usr/share/java
/usr/share/java/RXTXcomm-2.2pre2.jar
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/librxtx-java
/usr/lib
/usr/lib/jni
/usr/lib/jni/librxtxRaw-2.2pre1.so
/usr/lib/jni/librxtxI2C-2.2pre1.so
/usr/lib/jni/librxtxRS485-2.2pre1.so
/usr/lib/jni/librxtxSerial-2.2pre1.so
/usr/lib/jni/librxtxParallel-2.2pre1.so
/usr/share/java/RXTXcomm.jar
/usr/lib/jni/librxtxSerial.so
/usr/lib/jni/librxtxRS485.so
/usr/lib/jni/librxtxI2C.so
/usr/lib/jni/librxtxParallel.so
/usr/lib/jni/librxtxRaw.so

package/pi4j/Config.in line 3

Quoted 9 lines

package/pi4j/Config.in new file +3 -0

new file mode 100644
index 0000000..99736bf
@@ -0,0 +1,10 @@
+config BR2_PACKAGE_PI4J
+     bool "pi4j"
+     depends on BR2_PACKAGE_RPI_USERLAND

Why this dependency?

As stated above, we should ensure that a JVM is selected here.

package/pi4j/Config.in

Quoted 12 lines

package/pi4j/Config.in new file +12 -0

+define PI4J_INSTALL_TARGET_CMDS
+     $(INSTALL) -D -m 0644 $(@D)/lib/pi4j-core.jar \
+             $(TARGET_DIR)/opt/pi4j/lib/pi4j-core.jar
+     $(INSTALL) -D -m 0644 $(@D)/lib/pi4j-device.jar \
+             $(TARGET_DIR)/opt/pi4j/lib/pi4j-device.jar
+     $(INSTALL) -D -m 0644 $(@D)/lib/pi4j-example.jar \
+             $(TARGET_DIR)/opt/pi4j/lib/pi4j-example.jar
+     $(INSTALL) -D -m 0644 $(@D)/lib/pi4j-gpio-extension.jar \
+             $(TARGET_DIR)/opt/pi4j/lib/pi4j-extension.jar
+     $(INSTALL) -D -m 0644 $(@D)/lib/pi4j-service.jar \
+             $(TARGET_DIR)/opt/pi4j/lib/pi4j-service.jar
+endef

This can probably be improved a little bit:

PI4J_LIBS = core device example extension service

define PI4J_INSTALL_TARGET_CMDS

        $(foreach lib,$(PI4J_LIBS),\
                $(INSTALL) -D -m 0644 $(@D)/lib/pi4j-$(lib).jar $(TARGET_DIR)/opt/pi4j/lib/pi4j-$(lib).jar)

endef

Thanks!

Quoted 3 lines

I think this is quite certainly the first Java library for which we have a package. Which JVM are you using to run this on the target? The official Oracle JDK?

I'm using the official Oracle JDK. However I think we are not allowed to distribute it or make "recipes" to distribute it as part of buildroot, are we? Its license looks really restrictive. My current approach for the rootfs I'm building for a friend of mine is to install the Oracle jdk by using a overlay directory in buildroot. Do you think it would be possible to add the oracle jdk to buildroot?

Quoted 3 lines

Regarding the installation in /opt, I'm not sure. The fact that Raspbian installs it here is not that much of an argument to me (quite the opposite, actually!).

I put it there actually because it's a pre-compiled thing.

Quoted 11 lines

package/pi4j/Config.in line 3

Quoted 9 lines

package/pi4j/Config.in new file +3 -0

new file mode 100644
index 0000000..99736bf
@@ -0,0 +1,10 @@
+config BR2_PACKAGE_PI4J
+     bool "pi4j"
+     depends on BR2_PACKAGE_RPI_USERLAND

Why this dependency?

the same as for wiringpi. This package is specific to rpi and doesn't make sense on other platforms.

wiringpi has a really poor build system wrt cross-compiling and has no official release. These are the patches needed to cross-compile it in its latest revision.

This patch set was made hoping it would be merged by upstream. Therefore it's conservative on the changes. However the feedback was that "cross-compiling is wrong and you should fork it if you want to do so".

package/wiringpi/wiringpi.mk new file +0 -0

new file mode 100644
index 0000000..8e448ea

Dear Lucas De Marchi,

Quoted 3 lines · Lucas De Marchi

wiringpi has a really poor build system wrt cross-compiling and has no official release. These are the patches needed to cross-compile it in its latest revision.

We already had a patch that proposed to add this library in July 2013 (search for "Raspberry Pi - WiringPi Library Package" in the mailing list archives). At the time, the approach of the patch was to completely replace the package build system by a CMake based one. The patches were actually smaller than the ones you're proposing here:

 package/Config.in                                 |   1 +
 package/wiringpi/Config.in                        |   8 ++
 package/wiringpi/wiringpi-CLOEXEC-undefined.patch |  15 ++++
 package/wiringpi/wiringpi-cmake-support.patch     | 101 ++++++++++++++++++++++
 package/wiringpi/wiringpi.mk                      |  41 +++++++++

That being said, the big drawback of having a completely different build system is that everytime we will bump this library, we will need to do some close analysis to verify that our CMake based build system is aligned with what the official custom build system is doing. In that sense, I may in the end prefer your approach that consists in fixing the build system itself. This way, if it gets changed, then we'll automatically have these changes, or we will notice through conflicts that things have changed.

Also, looking at your patches below, only a few of them are in fact directly related to cross-compilation. Most of them fix various other issues, and maybe could be upstreamed.

Quoted 4 lines

This patch set was made hoping it would be merged by upstream. Therefore it's conservative on the changes. However the feedback was that "cross-compiling is wrong and you should fork it if you want to do so".

These RasberryPi people are really crazy. That some of them want to spend hours doing native builds on their RasberryPi is a thing, but that they force everybody to use those poor practices is really frustrating.

package/wiringpi/0002-Fix-typo-in-makefiles.patch line 6

Quoted 13 lines

package/wiringpi/0002-Fix-typo-in-makefiles.patch new file +6 -0

new file mode 100644
index 0000000..3145aa5
@@ -0,0 +1,187 @@
+From d87fbc10e372139736029009f0574e228776f205 Mon Sep 17 00:00:00 2001
+From: Lucas De Marchi <[email protected]>
+Date: Sat, 28 Dec 2013 18:26:13 -0200
+Subject: [PATCH 2/8] Fix typo in makefiles
+
+It's PHONY, not PHONEY.

This one can probably be upstreamed. Or maybe making typos is also part of the RasberryPi way of doing things? :-)

package/wiringpi/0004-Add-gitignore-file.patch line 4

Quoted 12 lines

package/wiringpi/0004-Add-gitignore-file.patch new file +4 -0

new file mode 100644
index 0000000..081d5be
@@ -0,0 +1,23 @@
+From 5f677acf115e1aa36d32a93164aa669d73c40fbf Mon Sep 17 00:00:00 2001
+From: Lucas De Marchi <[email protected]>
+Date: Sat, 28 Dec 2013 18:26:20 -0200
+Subject: [PATCH 4/8] Add gitignore file

I don't think we really need this patch in Buildroot.

package/wiringpi/Config.in line 4

Quoted 11 lines

package/wiringpi/Config.in new file +4 -0

new file mode 100644
index 0000000..1e7433a
@@ -0,0 +1,17 @@
+config BR2_PACKAGE_WIRINGPI
+     bool "wiringpi"
+     depends on BR2_TOOLCHAIN_HAS_THREADS
+     depends on BR2_PACKAGE_RPI_USERLAND

Is this dependency really needed? What does rpi-userland brings that is needed for wiringPi?

package/wiringpi/Config.in line 7

Quoted 4 lines

package/wiringpi/Config.in new file +3 -0

+     help
+       WiringPi is a GPIO access library written in C for the BCM2835
+       used in the Raspberry Pi.

I continue to be skeptical about the usefulness of such a library. Why not just use the /sys/class/gpio interface? But well, wiringPi seems to actually be used by some people, so we should have a package for it.

Quoted 11 lines

package/wiringpi/wiringpi.mk new file +4 -0

new file mode 100644
index 0000000..8e448ea
@@ -0,0 +1,28 @@
+################################################################################
+#
+# wiringpi
+#

package/wiringpi/wiringpi.mk line 10

Quoted 6 lines

package/wiringpi/wiringpi.mk new file +6 -0

+################################################################################
+
+WIRINGPI_VERSION = f18c8f7204d6354220fd6754578b3daa43734e1b
+WIRINGPI_SITE = git://git.drogon.net/wiringPi
+
+WIRINGPI_LICENSE = LGPLv3

License is LGPLv3+ it seems

package/wiringpi/wiringpi.mk line 13

Quoted 4 lines

package/wiringpi/wiringpi.mk new file +3 -0

+WIRINGPI_LICENSE_FILES = COPYING.LESSER
+
+PREFIX = /usr

No, this is not possible. Make variables in Buildroot are global, and we clearly do not want a global PREFIX variable to be defined.

package/wiringpi/wiringpi.mk line 26

Quoted 13 lines

package/wiringpi/wiringpi.mk new file +12 -0

+define WIRINGPI_BUILD_CMDS
+     env
+     $(TARGET_CONFIGURE_OPTS) $(TARGET_MAKE_ENV) PREFIX=$(PREFIX) $(MAKE) -C $(@D)/wiringPi
+     $(TARGET_CONFIGURE_OPTS) $(TARGET_MAKE_ENV) PREFIX=$(PREFIX) $(MAKE) -C $(@D)/devLib
+     $(TARGET_CONFIGURE_OPTS) $(TARGET_MAKE_ENV) PREFIX=$(PREFIX) DESTDIR=$(TARGET_DIR) $(MAKE) -C $(@D)/gpio
+endef
+
+define WIRINGPI_INSTALL_TARGET_CMDS
+     $(TARGET_CONFIGURE_OPTS) $(TARGET_MAKE_ENV) PREFIX=$(PREFIX) DESTDIR=$(TARGET_DIR) $(MAKE) -C $(@D)/wiringPi install
+     $(TARGET_CONFIGURE_OPTS) $(TARGET_MAKE_ENV) PREFIX=$(PREFIX) DESTDIR=$(TARGET_DIR) $(MAKE) -C $(@D)/devLib install
+     $(TARGET_CONFIGURE_OPTS) $(TARGET_MAKE_ENV) PREFIX=$(PREFIX) DESTDIR=$(TARGET_DIR) $(MAKE) -C $(@D)/gpio install
+endef

A better solution is probably:

WIRINGPI_MAKE_OPTS = \
        $(TARGET_CONFIGURE_OPTS) \
        PREFIX=/usr

WIRINGPI_DIRS = wiringPi devLib gpio

define WIRINGPI_BUILD_CMDS

        $(foreach d,$(WIRINGPI_DIRS),\
                $(TARGET_MAKE_ENV) $(MAKE) $(WIRINGPI_MAKE_OPTS) -C $(@D)/$(d))

endef

define WIRINGPI_INSTALL_TARGET_CMDS

        $(foreach d,$(WIRINGPI_DIRS),\
                $(TARGET_MAKE_ENV) $(MAKE) $(WIRINGPI_MAKE_OPTS) DESTDIR=$(TARGET_DIR) -C $(@D)/$(d) install)

endef

Also, I'm a bit surprised that it doesn't get installed in the staging directory (i.e WIRINGPI_INSTALL_STAGING = YES). If it's a library, to which other applications can get linked to, then it should be installed to the staging directory as well.

thanks for reviewing it, I'll send an updated version.

Dear Lucas De Marchi,

Quoted 1 line · Lucas De Marchi

thanks for reviewing it, I'll send an updated version.

Do you plan to resend new versions of your wiringpi and pi4j patches, taking into account the reviews that were made early January?