search

garrigue / lablgtk

LablGTK 2 and 3: an interface to the GIMP Tool Kit
https://garrigue.github.io/lablgtk
Other
90 stars 40 forks source link

lablgtk3 beta6 build-depends on camlp4 #78

Closed treinen closed 4 years ago

treinen commented 5 years ago

Hi,

somewhere between beta3 and beta6 a build-dependency on camlp4 seems to have creeped in, or at least dune thinks so:

dune build
        bash src/propcc.ml (exit 127)
(cd _build/default/src && /bin/bash -e -u -o pipefail -c 'camlp4o pr_o.cmo -impl propcc.ml4 -o propcc.ml')
/bin/bash: camlp4o: command not found
        bash src/varcc.ml (exit 127)
(cd _build/default/src && /bin/bash -e -u -o pipefail -c 'camlp4o pr_o.cmo -impl varcc.ml4 -o varcc.ml')
/bin/bash: camlp4o: command not found
File "src/dune", line 11, characters 12-29:
11 |  (libraries dune.configurator))
                 ^^^^^^^^^^^^^^^^^
Error: Library "dune.configurator" not found.
Hint: try: dune external-lib-deps --missing @@default

This the release of lablgtk3 tagged 3.0.beta6.

-Ralf.

ejgallego commented 5 years ago

The use of camlp4 is a developer-only dep, packages should invoke dune build -p $package which should avoid this problem.

The error related to dune.configurator seems more worrying, what dune version is this?

treinen commented 5 years ago

This is dune 1.11.0 (latest version in debian). I am compiling by invoking "dune build".

Even if camlp4 is developer only, that is if you distribute the preprocessed source code, this is in my opinion still a problem since the LGPL license says in the preamble:

  "Source code" for a work means the preferred form of the work for
making modifications to it.  For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the library.

Since your preferred form of modification is the code before preprocessing, I assume, the software should be compilable from that.

treinen commented 5 years ago

about the dune.configurator problem: that might be unrelated, I'm checking now

ejgallego commented 5 years ago

There is no licensing problem at all here, no more than people distributing a ./configure file instead of having the build call autoreconf.

Dune supports two compilation profiles, dev and release, in dev, you need developer tools such as camlp4, so indeed if you want to compile in that setup I don't see what the problem is, you should install camlp4.

Packages should never use the dev profile to build as it for example omits some linking optimizations, and has a set of warnings not suitable for package building. When you are in the release profile, camlp4 is not required either as it is only used for re-generating some dev-only scripts.

ejgallego commented 5 years ago

You can also build in dev mode but skip the promotion of auto-generated files by using the --ignore-promoted-rules flag.

ejgallego commented 5 years ago

Indeed after a quick look to ocaml-team @ salsa, dune packaging seems to need more work, likely a dh_dune should be implemented.

For example this is not doing the correct thing:

this seems OK tho:

treinen commented 5 years ago

@ejgallego: thanks for the --ignore-promoted-rules flag, that solves the problem with dune.configurator for me. It compiles now fine in a minimal chroot without camlp4 installed.

I not sure about the license problem, though. To take up your analogy: distributing a ./configure is of course not a problem. However it would be a problem if the files necessary to rebuild a ./configure using commonly avallable free tools are not distributed. And camlp4 is soon losing its status of commonly available.

ejgallego commented 5 years ago

@ejgallego: thanks for the --ignore-promoted-rules flag, that solves the problem with dune.configurator for me. It compiles now fine in a minimal chroot without camlp4 installed.

I am a bit puzzled tho, why would you ever want to compile with this setup?

I not sure about the license problem, though. To take up your analogy: distributing a ./configure is of course not a problem. However it would be a problem if the files necessary to rebuild a ./configure using commonly avallable free tools are not distributed. And camlp4 is soon losing its status of commonly available.

This has absolutely nothing to do with licensing; as of today, files are properly distributed.

You are wondering about what will happen in a few years, as camlp4 will be maintained at least until OCaml 4.10. Even so that would not be a licensing problem, at worst it could mean that lablgtk3 requires OCaml < 4.11 to work. Following your logic, most gtk2 applications have license problems then.

We are aware of the end-of-support timeline for camlp4 and indeed we hope to port the tooling to a different parsing engine at some point.

treinen commented 5 years ago

Why compiling in a minimal chroot ? This is to check that I have correctly declared all the build-dependencies of the debian package, before uploading to the debian archive. Otherwise the build demons will fail.

ejgallego commented 5 years ago

You are using the wrong dune invocation then, you should use the -p form inside the chroot if you are testing a package build.

Dev profile must not be used for packaging.

olafhering commented 5 years ago

Was any work done to replace the usage of camlp4 with something else? There should be no generated files in a SCM...

garrigue commented 5 years ago

Yes, you can use camlp5, which is still maintained.