Skip to content
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

Separate the build of ocamlbuild, ocamldoc, ocamldebug (non-mandatory tools) from the build of the compiler #6773

Closed
vicuna opened this issue Feb 8, 2015 · 8 comments

Comments

@vicuna
Copy link

@vicuna vicuna commented Feb 8, 2015

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.

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 8, 2015

Comment author: adrien

Forgot to say that this is most probably going to conflict with the patch in #6266 but this shouldn't prevent #6266 from hitting 4.02.x since I expect these patches to take more time to integrate.

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 10, 2015

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.

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 10, 2015

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)

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 10, 2015

Comment author: @lpw25

Personally, I do make world, make install, and then use the installed debugger on the installed ocamlc. (This seems to require me to manually add -g to the Makefile, which is slightly annoying)

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 15, 2015

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.
http://cgit.notk.org/adrien/ocaml/commit/?h=mantis-6773-separate-build-of-ocamldoc-ocamlbuild-ocamldebug-v2&id=c8f64816345bf8efcecb008ef4c7c11e89fc7c21

ocamlbuild: remove the "light" mode.
http://cgit.notk.org/adrien/ocaml/commit/?h=mantis-6773-separate-build-of-ocamldoc-ocamlbuild-ocamldebug-v2&id=d6269cb05cce5ef6d69939cdcc6115be73529d03

ocamlbuild/ChangeLog: remove since last change dates back to 2007.
http://cgit.notk.org/adrien/ocaml/commit/?h=mantis-6773-separate-build-of-ocamldoc-ocamlbuild-ocamldebug-v2&id=a3983e38a0305596912e8c28b1246c57ae14b065

ocamlbuild/start.sh: unused, remove
http://cgit.notk.org/adrien/ocaml/commit/?h=mantis-6773-separate-build-of-ocamldoc-ocamlbuild-ocamldebug-v2&id=ae1ccd1ed51720adf9d4c0490c2feda916129de5

ocamlbuild/Makefile.noboot: remove since it's unused.
http://cgit.notk.org/adrien/ocaml/commit/?h=mantis-6773-separate-build-of-ocamldoc-ocamlbuild-ocamldebug-v2&id=3427c008dc5dae357ac02444c7e92c2f924f3158

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.

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 18, 2015

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.

@vicuna
Copy link
Author

@vicuna vicuna commented Mar 4, 2015

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).

@github-actions
Copy link

@github-actions github-actions bot commented May 11, 2020

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.

@github-actions github-actions bot added the Stale label May 11, 2020
@github-actions github-actions bot closed this Jun 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant