-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for out-of-source builds by make scripts of this software #245
Comments
I don't think there is any practical benefit to almost any ocamlbuild user or developer but any PRs implementing this are welcome. |
Hi Markus, From my point of view, these features are low-priority. The vast majority of ocamlbuild users use it through OPAM, so they don't care how it is build internally as long as the build is not embarrassingly slow. The features of its Makefile are only relevant to its developers, and I personally don't care much about improving it -- my time is limited and there are many other things that I feel are more important. So I won't invest time to support these features; but of course I am not opposed to others doing so if they see a need for it. If you have pull requests / patch proposals to support these, I would be happy to merge them as long as they don't make the codebase harder to maintain or inconvenience people not using them. |
Would you ever like to store your source files for this special build tool in a read-only directory? |
No one builds ocamlbuild like that. |
|
We are not interested in discussing the merits of out-of-tree builds, which are well-understood. We do not have any plans to support out-of-tree builds in ocamlbuild. You are welcome to implement them. |
|
OCaml itself can be built with nmake; I'm not sure about ocamlbuild but so long as OCaml can be built with nmake it would be nice if ocamlbuild could also be built with nmake. However, I've heard that OCaml is being migrated to GNU autotools (which of course precludes using nmake). @gasche, do you know anything about this? Was that just about the configure script? |
I think that it is now a consensus among the OCaml development team that it is ok to rely on features of GNU make that do not exist in, say, BSD make. I think there is indeed a plan to use autotools for configuration, but I don't know the details. (Given that most systems have GNU Make available these days, I was under the impression that assuming it does not restrict portability.) |
I imagine that the special variable “VPATH” could be supported together with other usual make variables already. |
I have achieved a bit of progress with building your software by the approach “Automake”.
How can the affected source code be improved? |
I cannot reproduce the fact that |
I am trying to get the Automake approach working based on your commit (from 2017-06-23) together with the software “OCaml 4.03.0-3.1” on my openSUSE Tumbleweed system. |
It seems that my knowledge is incomplete for another software dependency so far.
How should this issue be tackled? |
It seems that your experiment to improve the build system have broken the build. I don't know what you are trying to do, so I'm afraid I don't know how to help you. Note that, as mentioned earlier, I'm not sure that the feature you are trying to implement will actually be useful to our users. (It might be useful to you, but you haven't yet explained why.) If you want to contribute to OCamlbuild, you are of course free to work on anything you choose, but there are other features that our users asked for and that I hope would not be too difficult to implement, and could be a good use of your time/effort; see #226 and #215 for example. |
This software build alternative is just evolving as usual. I find that the make script which is used so far does not express a direct source dependency on the file “ocamlbuild.cmo”.
Are you aware of benefits from using Automake for safer software builds? |
See the There is a dependency from |
The file “ocamlbuild.ml” is using the specification “Ocamlbuild_pack.Main”. |
Can any progress be achieved for the following information?
The command variant “
|
…on working together with Autoconf and Automake The provided make script contained restrictions for storage locations according to the combination of source files and the corresponding generation of further file variants. These software limitations were lifted by the addition of two build scripts which use functionality from the tools “Autoconf” and “Automake” to some degree. Some build settings were adjusted in the way that make rules are automatically constructed by special function calls. The dependency on the tool “GNU Make” was expressed then. This development result is published despite of known open issues. Examples: 1) Generation approach for the manual with the version “OCaml 4.03.0-3.1” on an openSUSE Tumbleweed system elfring@Sonne:~/Projekte/Bau/OCamlbuild> rm -f man/options_man.byte && LANG=C OCAMLRUNPARAM=b make man/ocamlbuild.options.1 … man/options_man.byte > man/ocamlbuild.options.1 Fatal error: exception Invalid_argument("String.sub / Bytes.sub") Called from unknown location Called from unknown location make: *** [GNUmakefile:859: man/ocamlbuild.options.1] Error 2 2) Difficulties with parallel software builds A command like “ocamlc.opt -pack” will be called by a make rule. It has got the property that three output files can be generated. Such a detail causes recurring challenges for the safe application of the involved software so far. https://www.cmcrossroads.com/article/rules-multiple-outputs-gnu-make https://lists.gnu.org/archive/html/help-make/2014-11/msg00013.html 3) The test scripts for this evolving tool will need related updates. They were left over for further development considerations. 4) The selection of default values for a working build configuration could eventually become more convenient and safer then. Signed-off-by: Markus Elfring <[email protected]>
How do you think about to benefit from parallel build trees also for your software?
Would you like to support out-of-source (VPATH) builds?
The text was updated successfully, but these errors were encountered: