WIP: configure script

[nolta]

Adds a gnu-like pre-make configuration step, e.g.,

$ ./configure --prefix=/path/to/install FC=gfortran-mp-4.9
$ make

[tkelman]

This is a huge pet peeve of mine. Don't pretend to be autoconf. It never works very well (and I've seen it done poorly many times - Rust, git, Flint, BLIS, etc), what you inevitably end up with is autoconf but worse. This would be better-handled via cmake. ref #3118 (which this would partially address) and #8937 (comment)

[nolta]

My feeling is that neither autoconf nor cmake work well for large, complex projects. We're better off just rolling our own.

[tkelman]

I feel exactly the opposite, rolling your own is a terrible idea especially if you're a large complex project (unless you have Google's resources, I guess). If you want autoconf, you should use autoconf. Full autotools would give good cross-compiling and out-of-tree builds. Cmake would give out-of-tree builds and first-class msvc support and standardized dependency handling. This gives us a few configure-time checks that compilers are present and working, and changes the syntax by which we provide configuration options. We have a hard enough time maintaining thousands of lines of confusing custom makefiles, let's not add to that with hundreds more lines of confusing custom bash.

[tkelman]

I could get behind this if it were optional to start with, and strictly a Make.user-generator and build-tool-checker. I believe that's how git's build system has things set up.

[nalimilan]

What features does your configure script bring? Dependency checking sounds like it would be useful, but what more?

Is CMake able to check for dependencies automatically? I share @tkelman's concerns about having to maintain a big set of shell scripts that everybody is afraid to touch. Reinventing the wheel in such an horrible area of software development is not really appealing...

[ViralBShah]

I share the same apprehensions. I do think this is a good idea as a make.user generator. We probably should not call it configure, or else distro tools will barf thinking this is the full thing.

[tkelman]

Is CMake able to check for dependencies automatically?

There's a whole pile of check_* and find_* functions in cmake for doing this. Works quite well.

We probably should not call it configure, or else distro tools will barf thinking this is the full thing.

Have had exactly this experience. If you call it configure, you should really support out-of-tree builds and every possible flag that autoconf does, otherwise debhelper and spec file macros are going to have a hard time with it.

[nolta]

This PR has gotten off to a bit of a rocky start, and that's partly my fault for being too laconic.

This is a bash script to generate Make.user (renamed to config.mk). The goals are:

• adopt a familiar configuration interface.
• catch errors earlier, not 45 minutes into the build.
• freeze the configuration, so changing environment variables don't accidentally screw up devel builds.
• remove the need to set redundant variables like USECLANG -- test for them instead.
• fix a few bugs (e.g., some of Build error with Intel Compilers v15 on OSX #9145).
• slightly prosaic, but makefile lacks case statements, so some of the logic is a little easier to read in bash (thought perhaps this is just me).

It supports cross-compiling (i've tested it on cygwin). It can support out-of-tree builds. It can do anything our makefiles can do.

As for some of the objections:

• It shouldn't be called configure: Ok, i'm happy to change it. How about config?
• It's a big, nasty bash script: Yes. But i think it's preferable to a big, nasty makefile, because you don't have the added complexity of lazy evaluation.
• It should be optional: I'll think about this. At the moment i'm against it, because i expect we'll end up duplicating a lot of the logic.
• It's not cmake: Yes. It's just an attempt to improve our custom build system, without replacing it wholesale.

[tkelman]

It can support out-of-tree builds

How? You can run ../configure sure, but the makefiles won't exist from any other directory so then calling make won't work. This isn't full autotools.

The goals are good, but this is going to have to be optional at first otherwise there's no migration plan and we'll get a dozen issues and mailing list posts saying "make errored, could not find config.mk."

It's a big, nasty bash script: Yes. But i think it's preferable to a big, nasty makefile,

Net, you're adding more in bash than you're deleting from Make.inc. We currently don't use bash all that heavily in the build system.

[nolta]

This isn't full autotools.

Fair enough. Our builds are only semi out-of-tree.

we'll get a dozen issues and mailing list posts saying "make errored, could not find config.mk."

Just add a new makefile target:

$(JULIAHOME)/config.mk:
    $(error please run configure)

Net, you're adding more in bash than you're deleting from Make.inc

Sure, but with new features.

[vtjnash]

i like this. it seems to be exactly the missing piece for finishing the out-of-tree compile work, which is nearly finished, but pretty much requires a ./configure-like script to make work.

i agree with the comment that it shouldn't be named ./configure if it's not an autoconf-derived script. how hard would it be to modify this PR to generate the same output, but using autoconf instead of sh?

[schnaitterm]

@tkelman

(unless you have Google's resources, I guess)

even with their resources, it's probably not going to be good... have you ever used Bazel? shudder