Dear Eric, First of all, many thanks for your prompt and precise response, warmly appreciated. Eric Blake (2018/10/02 10:40 -0500): > On 10/2/18 10:15 AM, Sébastien Hinderer wrote: > > Dear 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? > That 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. :) > > And, 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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
