Build error - "Makefile:20: *** missing separator. Stop."

[timbertson]

I tried with both a git checkout and also the release tarball (https://github.com/michipili/opamconfig/releases/download/v0.3.0/opamconfig-0.3.0.tar.gz), and I get:

$ ./configure --prefix=$(pwd)/install
checking for apk... no
checking for apt... no
checking for apt-get... no
checking for aptitude... no
checking for brew... no
checking for dpkg... no
checking for emerge... no
checking for nix-env... /home/tim/.local/nix/bin/nix-env
checking for ocamlfind... no
checking for pacman... no
checking for pkg... no
checking for pkg_add... no
checking for port... no
checking for setup.exe... no
checking for yum... /usr/bin/yum
checking for zypper... no
configure: creating ./config.status
config.status: creating Makefile.config
config.status: creating opamconfig_conf.sh

$ make
Makefile:20: *** missing separator.  Stop.

That line is .include "shell.prog.mk". I'm not sure whether that means it can't parse that line, or can't parse the included file (which isn't in the current directory - not sure where it's supposed to come from)

I'm interested in making sure that if opamconfig gets adopted by opam packages, they keep working under opam2nix (because I'm pretty sure it won't without intervention). So I'm also curious that it's checking for nix-env - is it nix aware, or is that just some autoconf guff?

Having not been able to try it out yet, I'm also curious how it relates to pkg-config. I guess the underlying problem may be that packages (like gmp, in the case of conf-gmp) may or may not provide pkg-config setup depending on the distro. I don't know much about the internals of pkg-config and how awkward it is to work with, but it does seem like opamconfig is aiming to do a lot of the same things.

[foretspaisibles]

Hi @timbertson, thank you for your detailed bug report.

1. Installation As opamconfig is in a rather early development phase I did not write a complete setup for it yet. The Makefiles are actually here as a ”developer commodity” (for instance, we can produce GPG-signed tarball with make dist) but they are not needed to install the software, the sequence

autoconf
./configure --prefix=…
sh ./opamconfig_install.sh

or to test the software, you can use

autoconf
./configure --prefix=…
sh ./opamconfig_test.sh

and add more tests in the ./opamconfig_test.sh file.

That said, you can use the pinning feature of opam to install and test opamconfig.

If you are curious about the Makefile features, they have two prerequisites:

1. The bmake program, it is a Make Program from the BSD realm, which is much easier to program than GNU Make. You probably can install this program using the package manager of your distribution.

2. The bsdowl macros, https://github.com/michipili/bsdowl

2. Autodetection of nix

The goal of opamconfig is to give a consistant approach to detection of libraries provided by the system or by the user. To do this, it uses the simple heuristic of detecting package managers on the system (so it looks for distribution-specific package managers, but also language-specific like pip, and variants like port and brew in macosx).

If you want to experiment with it, see the following branch of the opam repository displaying the use of opamconfig for conf-gmp and zarith:

ocaml/opam-repository#8352

It shows how the conf-* package is responsible of detecting the configuration options needed to use the library gmp, and then how to use the settings to build the zarith package.

[foretspaisibles]

Having not been able to try it out yet, I'm also curious how it relates to pkg-config. I guess the underlying problem may be that packages (like gmp, in the case of conf-gmp) may or may not provide pkg-config setup depending on the distro. I don't know much about the internals of pkg-config and how awkward it is to work with, but it does seem like opamconfig is aiming to do a lot of the same things.

opamconfig is not very relevant in itself, the important point is that conf-* should detect compilation options to libraries and also save them for other packages to use. (In the current state, the detection is often duplicated in non conf-* packages, because the results from conf-*.)

I wrote opamconfig because many opam files derive compilation options from the os variable which does not work well enough on Mac OS-X systems, or on systems where PKGSRC is used, or when a non-standard installation prefix needs to be used. So opamconfig tries to provide a heuristic that works in more cases and is intended as a simple tool to fix broken opam files.

When libraries provide information that can be used with pkg-config the opam file can probably be written without opamconfig and, if someone has the knowledge and energy to improve the upstream package, so that it uses pkg-config this provides a second, better but longer, mean to fix the installation procedure of an opam package.

That said, maybe opamconfig could be taught how to format information retrieved by opamconfig so that it can be easily saved as opam-style configuration information. What do you think about this?

[timbertson]

The Makefiles are actually here as a ”developer commodity” (for instance, we can produce GPG-signed tarball with make dist) but they are not needed to install the software

Oh right, that makes sense. I should have been able to figure this out, as I had read the opam file and saw that it wasn't using make.

Thanks to this, I've managed to get it working. Firstly, I think you need a shebang line in the installed bin/opamconfig - it works in bash, but can't be invoked as a program from fish, python or other programs which use plain execvp instead of whatever sneakiness bash is doing. That's a minor issue though.

After using it, I now understand how it works a bit better. I'm afraid I didn't understand from the readme, because it seemed too simple to simply invoke opamconfig with the compilation instructions - how does the conf-* package tell it what flags to save?

I've now figured out it goes something like:

• guess some values for CFLAGS, LDFLAGS, etc based on heuristics
• run the test compilation command (passed as arguments)
• if it succeeds, save these to the output file in a format opam can use
• if it fails, proceed to the next guessed set of flags and try again

(Obviously you know this, but understanding how I think of it may help explain it to others)

I didn't realise this, but apparently opam already looks in {pkgname}/{pkgname}.conf for configuration flags? I wasn't sure how opamconfig was injecting itself into opam, but if that's how it works then that makes sense (and is something I may need to replicate in opam2nix)

opamconfig is not very relevant in itself, the important point is that conf-* should detect compilation options to libraries and also save them for other packages to use. (In the current state, the detection is often duplicated in non conf-* packages, because the results from conf-*.)

Yes, I dislike that a lot and am happy to see someone trying to address this!

That said, maybe opamconfig could be taught how to format information retrieved by opamconfig so that it can be easily saved as opam-style configuration information. What do you think about this?

Yes, now that I understand how it works, opamconfig could adopt pkgconfig as another heuristic (probably a very high priority one, since if pkgconfig works it's probably the most reliable option).

I imagine opamconfig would need a new option to indicate what pkg-config package(s) it should try, and then it could try getting CFLAGS (etc) from pkg-config. If that works, and the resulting settings compile, the relevant flags could be saved in the opam config file so that the opam package depending on the conf-* package could benefit of pkgconfig without having to detect pkg-config and figure out an appropriate fallback if it's not there (I've had people complain in the past when I introduced a hard dependency on pkg-config, as it's not readily available on some systems).

(I'll close this issue since the compilation error is fixed, but I'll open a sepatate issue for opam2nix specific notes)