Re: Arguments for OCaml build configuration

[SF Markus Elfring]

> So far, the OCaml compiler is configured with a handwritten 'configure'
> shell script which behaves a bit similarly to an autoconf-generated
> script, but not completely. My current task is to replace this
> handwritten shell script by an autoconf-generated one and to make it
> possible to use the compiler for doing cross-compilation.

I find such a software transformation also interesting.
Would you like to consider the possibility that such configuration scripts
can be generated by other software build systems, too?


> Coming to the directory I was talking about, it is currently called
> "target-bindir" and is used to define where the bytecode interpreter,
> ocamlrun, will reside on the target system.

How many compreters do need a separate directory selection parameter
for their executable files?
https://en.wikipedia.org/wiki/Bytecode#Examples


> This is something the compiler running on the host needs to know
> because it adds a line like
> #!/path/to/ocamlrun/on/target/system
> at the beginning of the bytecode executables it produces, so that they
> can then be run as regular executable programs on the target.

Will any more configuration arguments become relevant for the construction
of the desired shebang?


> I may also add that target-bindir could be considered as just one
> particular instance of things one may want to specify at configure time.

I guess that you will try this design variant out before you can move
this setting into other scripts.
How do you think about any software extensions for the GNU autoconf archive?
https://www.gnu.org/software/autoconf-archive/


> Coming back to the original directory problem, I think I can handle it
> with an argument like '--with-target-bindir=' but that's perhaps not the
> best / recommended way?

Why did you become concerned for such a software design direction?


> Then recently it has been decided not to install the bytecode versions
> by default and a configure option has been default to request them
> to be installed. This option has been called '--install-bytecode-programs',
> which in my opinion makes sense. So we could use e.g.
> '--enable-installing-bytecode-programs' but again we have no way
> to deprecate the old name slowly.

You describe effects from usual software evolution. Now it seems
that you stumble on a conflict because of the GNU Coding Standards.
Would you like to comply with them completely?

How do you think about to pass the parameter “foreign” to
the macro “AM_INIT_AUTOMAKE”?
https://www.gnu.org/software/automake/manual/html_node/List-of-Automake-options.html

Regards,
Markus