Do not pass the -toolchain option when building a plugin #160
Conversation
|
This PR will need an update once #159 is merged, I think. |
|
I have bad gut feelings about the idea of removing the ability to use I thought of proposing also having |
|
(Making plugin-option less painful to use, for example with a |
I don't believe anyone in the entire history of OCaml development has wanted the first two. "I don't know" gives a good hint. Therefore I do not wish to waste my time implementing this feature you suggest. |
|
I have certainly seen people in the wild use |
|
Sigh. Nevermind. I'll just instruct the users of opam-cross-* repositories to pin my fork of ocamlbuild instead. |
|
So maybe users with specific plugin-build needs could actually run the more verbose two-step process where they first |
You may be tired or angry about something else, but pouting because I am thinking out loud about your feature before integrating it is not particularly nice. I want to do the right thing and I appreciate your work, but I also have to make sure that I understand the pros and cons and proposed changes -- many of the current silent users of ocamlbuild don't particularly ask for new features and just want the shit to keep working, which is in tension with the newly proposed features (as the |
I recall you've mentioned on many occasions that splitting ocamlbuild from the compiler was going to enable it to evolve faster. I don't see that happening. In fact over the last many months, every time I came back to the OCaml ecosystem, there was simultaneously more complexity and more brokenness in the build systems, and not that much interest in improving the situation. But sure, let's try this again. |
I consider this unacceptable. This is broken in principle (sharing the options for building host and target software should never happen) and in practice (e.g. the users of topkg that override |
I think this is acceptable. I'm now implementing support for |
|
@gasche Please review the updated PR. |
The reasoning, I think, was that having it an independent, less-scary project may remove some psychological barriers that people would have to contribute. (There were no strong practical barriers at the time, in the sense that it is not too hard today to get code integrated in the language implementation.) Of course, I could not tell whether this would actually work or not (I was never a big proponent of the move, it's just that I did not oppose it and I think the ability to have desynchronized releases, in principle, makes sense). But the people that told us that they would be willing to contribute in fact do not, I suppose that they don't actually have the time to do it, so we have exactly as much contributions now than before the split, that is not very much -- you would be the notable exception. Note that if you were willing to take a more active role in the maintenance of ocamlbuild, I would of course be happy to let you. (I believe that you have full commit rights, so technically there is nothing more to be done.) I am not very good at being a maintainer. But if nobody steps up, well that's how it is. And I think that our duty to the OCaml community is mostly to ensure that ocamlbuild keeps working for the people for which it works today, and of course let people that decide to build interesting things off it have some control over its improvement. One reason why I'm slow to work on ocamlbuild is that there is always something higher in my priority queue, even whithin the OCaml community: right now I have been working on making sure the future 4.05 release works well, and that, in fact, does not require any ocamlbuild-side change (actually, before we interacted this week-end I was thinking of porting ppx_deriving to use ocaml-migrate-parsetree; I did not decide otherwise, but just didn't have the time to do it). |
I did. Assuming you're watching the repo, you've got the notification about me adding Travis support, and you've seen my build system changes already. Once that lands there won't be another mtime fiasco, at least. Incidentally what do you think about removing support for platforms without the Unix module? Does this still really matter for anybody? There's so much poorly exercised code lying around... The current buildsystem is not even able to build it.
That would be warmly welcome. |
|
This fix might interact with (solve?) #66. |
A plugin is always built for the same platform ocamlbuild is.
It is therefore always a mistake to pass the -toolchain option
to ocamlfind when building a plugin. More generally, the compiler
that is used for building the plugin and the user code should be
possible to set separately.
This necessarily results in four new command-line options:
* -plugin-ocaml{c,opt}, which are like -ocaml{c,opt} but only
for building the plugin;
* -plugin-{no,use}-ocamlfind, which are like -{no,use}-ocamlfind,
but only for building the plugin.
To preserve compatibility, the old -{use,no}-ocamlfind options imply
the new -plugin-{use,no}-ocamlfind. It is still possible to have any
combination of using ocamlfind for build or host code by ordering
the -plugin-{use,no}-ocamlfind options after -{use,no}-ocamlfind
ones.
Note that the -cflag, -lflag, etc., options were never used
when building the plugin and are therefore not touched by this
commit.
|
The new patch lifted my concerns, thanks. I am still a bit unsure about the |
By reading the --help text (or the manpage... which should be probably updated). It also seems very counterintuitive to use one set of options when we are building with the plugin, as opposed to building the plugin, so I'm not sure how common would this interpretation be. It took me a few moments to understand the semantics of your other option. |
|
You seem to hold your position strong :-) I merged. |
|
According to my testing there seems to be a bug in the -toolchain option handling, when used in the wild. Investigating. |
|
Oh, sorry, nevermind. I forgot to update my local master branch after the merge... |
2 participants
See the commit message. cc @gasche