Dear Eric,
First of all, many thanks for your prompt and precise response, warmly
appreciated.
Post by Eric BlakePost by Sébastien HindererDear all,
Is there a way to add a new "directory category", in addition to bindir,
libdir, etc.?
Which directory are you thinking? Is it standardized somewhere, like GNU
Coding Standards, Linux File System, or similar? If it is worthwhile,
autoconf should be providing that directory for everyone rather than you
having to add custom code to support it. Otherwise, why is your project
special that it needs a directory that is not standardized, and can you
fully justify why the existing directories are insufficient for your needs?
I don't have any definitive answers to your questions so let me give the
context and perhaps we will be able to figure them out together.
I am working on the compiler for the OCaml language
(http://www.ocaml.org). For those who don't know, OCaml is a functional
programming language. It can be compiled either to bytecode which is
then executed by a bytecode interpreter written in C and called
ocamlrun, or to native code for different architectures.
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.
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. 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. Does all
this make sense? Perhaps autoconf has a different way of handling such
settings?
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.
How, for instance, would one deal with a situation where the libdir
differs between host and target?
In the same vein, I was wondering why the 'AC_SYS_INTERPRETER' macro
doesn't come in three variants, one for build, one for host and one for
target because I imagine that one may want to know whether #! is
supported on each of these platforms. Well perhaps not on the build
system, but, at least for us, that would matter for both host and
target.
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?
Post by Eric BlakeThat said, commit a19743141 shows the addition of --runstatedir, as once
such example of a globally-useful directory worth supporting, in response to
GNU Coding Standards adding a variable for this directory in reaction to
many distros preferring /run over /var/run when installing into /. And, I'm
woefully low on free time, as that commit has not yet appeared in a released
version of autoconf (2.69 predates it, and I really need to get 2.70 out the
door).
No problem! Many thanks for the pointer to that commit! It can indeed
help since, I think, we will distribute a generated configure, although
I don't like this approach too much, well that would give a reason to do
so. Perhaps not the best reason, but still, a reason. :)
Post by Eric BlakePost by Sébastien HindererAnd, more generally, is there a way to make a configure script accept
arguments that have a shape different from --with, --without, --enable
and --disalbe?
No, not without going against the GNU Coding Standards, which state that a
configure script shouldn't need any other option prefixes. Again, what is
the exact semantics you are hoping to add, and why are the existing
mechanisms inappropriate for those semantics? A strong justification is
needed, at which point maybe we can work on amending the GNU Coding
Standards to document your use case for everyone to be able to share
it.
Many thanks for your openness. Well beyond the particular semantics we
are trying to achieve, I think one reason for being more permissive
about the syntax of arguments would be to help people in situation
similar to mine maintaining backwards compatibility. Indeed, even in the
cases where the arguments have been poorly named, I think it would help
to be able to still use them and then deprecate them slowly, rather than
being forced to change them brutally.
Now coming to the needs we may have and where the existing possibilities
might perhaps not be enough, well while building the compiler we build
most of its programs in both bytecode and native format. Until recently,
we installed both forms, the native ones being more efficient but the
bytecode ones being more easy to debug. 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. And there are a
few other options of this kind, plus some others which take values but
for them I guess we can use the '--wit-some-variable=value', although I
undrstand that the '--with' options are here for dependencies on
external packages. Perhaps it would be interesting to extend the meaning
of such options to allow the usecase I just described.
And finally, our current, legacy configure script has the tendency to
accept arguments no matter whether they start with one or two dashes, so
for example for the argument given above, both
'--install-bytecode-programs' and '-install-bytecode-programs' are
accepted, but I think it's okay to drop the single-dash version so I
mention this part just to try to be complete.
Sébastien.