Separate the build of ocamlbuild, ocamldoc, ocamldebug (non-mandatory tools) from the build of the compiler #6773
Comments
|
Comment author: @garrigue I would suggest to keep ocamldebug inside the compiler, as it is needed to debug the compiler itself, and having it out of sync might cause major problems. |
|
Comment author: adrien These patch don't move any of the tools and a single commit will still be able to change both the compiler and the debugger. While it is debatable for the other tools, I don't think it makes sense to have the debugger in its own repository. (NB: this is probably similar to binutils and gdb: gdb lives inside binutils' tree and the tarballs for gdb are extracted from that tree) It's possible to have things out of sync if you rebuild only one and not the other however. One thing still missing in this patch series is makefile rules that build both the compiler and given tools. I'd like to know more about the workflows of the people who regularly work on the compiler. How do you run ocamldebug (i.e. which ocamlrun, and which parameters)? At which stage do you run it? I expect that there is at least some inconsitency anyway like the standard lib not having been rebuilt yet. Do you have a step-by-step example of when you run it? (i.e. something like: build everything, change file X, rebuild ocamlc but nothing more, run the debugger on that ocamlc's output while still using the cmo/cma from the previous build) |
|
Comment author: @lpw25 Personally, I do |
|
Comment author: adrien I've pushed a branch which is rebased on trunk and with a couple more patches http://cgit.notk.org/adrien/ocaml/log/?h=mantis-6773-separate-build-of-ocamldoc-ocamlbuild-ocamldebug-v2 . The commits are fairly minor: build: add "opt" targets to ocamlbuild and ocamldoc for consistency. ocamlbuild: remove the "light" mode. ocamlbuild/ChangeLog: remove since last change dates back to 2007. ocamlbuild/start.sh: unused, remove ocamlbuild/Makefile.noboot: remove since it's unused. As for ocamldebug, I still don't know what to do since I don't have many inputs: it's small and I don't need it myself but I'd like to have full coverage for the tools. I want to be able to cross-compile the compiler since that will make the creation of windows installers tremendously simpler. Not having a separate build for the debugger is not going to be an issue: its build is simple, bytecode-only and it's really not useful while building a cross-compiler so it can be disabled. |
|
Comment author: @damiendoligez I mainly use the debugger to debug the runtime, and the way I do it is to fully bootstrap and install the system, then change the runtime, then use the installed debugger on the (crashing) compiler. So I'm basically using it outside of the bootstrap loop. |
|
Comment author: adrien I have again some free time to work on this but I'm not sure what to do about the debugger. Jacques, how do you install/run it? I can keep the builds tied together but I'd really prefer to split them as it'd remove the needs to locate libraries the compiler installs (again: split the builds, not the sources). |
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Original bug ID: 6773
Reporter: adrien
Status: acknowledged (set by @damiendoligez on 2015-02-18T23:14:29Z)
Resolution: open
Priority: normal
Severity: feature
Target version: undecided
Category: configure and build/install
Tags: cross-compilation
Monitored by: @Drup jpdeplaix @hcarty
Bug description
This is the first and untested version of a series of patches to separate the build of the non-mandatory tools from the build of the compiler itself.
This can lead to splitting them from the sources too or not. There are only two reasons for me to do that: make it simpler to hack on the build system by having less to do at once, and avoid the need to wonder which compiler and build options to use when doing cross-compilation and one of these tool is enabled (and also make their build under such scenarios simpler).
As I said above, this is not tested. I've tried it on my linux machine but that's it. Separate bits have been tested on BSD and Windows has been kept in mind but I haven't tested them yet since I'm expecting some discussion on whether the build split should be done or not.
There are 5 commits: 4 small ones and one large. They are hosted on my own git repository with no extra step. I will use whatever is deemed best (branches, tags, one per new batch or not, named after the day or not, ...) [ except github since their ToS are impossible to abide to ].
compiler-libs: also install .cm{o,a,x} files.
http://cgit.notk.org/adrien/ocaml/commit/?id=942ec21b0ffd9dc1849992f3f8d2e6b5838b7489
ocamldoc/Makefile: $UNIXLIB/unix.mli's content doesn't depend on $UNIXLIB.
http://cgit.notk.org/adrien/ocaml/commit/?id=b457ca398a68d05ef69e0e03b4f82b6d7d84f38d
ocamldoc/Makefile: replace remove_DEBUG script with a single awk invocation
http://cgit.notk.org/adrien/ocaml/commit/?id=a5c4cb232c626346fa5fec957948869c1ee56753
ocamldoc/Makefile: don't "test -d" before "mkdir -p".
http://cgit.notk.org/adrien/ocaml/commit/?id=8fd3507127ac683825ccba3d98ad3048525b2acc
debugger, ocamlbuild, ocamldoc: separate their build from the compiler's.
http://cgit.notk.org/adrien/ocaml/commit/?id=9aa69ae40db1cf8484d0caadb1da2d88f2038ddc
(that's the large one, in particular since it contains upates to .depend files (they shrink a lot))
The point that might not be welcome is that this makes building these tools slightly more involved. It's quite simple and doesn't require the fresh compiler to be installed system-wide but it requires a change of habits. It's quite easy to automate the building as usual too if that's wanted. In other words, if your usual workflow prevents you from configuring ocaml with -no-debugger -no-ocamlbuild -no-ocamldoc, then you might be opposed to this patch series.
The text was updated successfully, but these errors were encountered: