Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Merge build systems in the byterun directory #981
This time, the PR contains several commits showing how variables and
The story may look a bit long (in terms of commits), but it should also
Once the reviewing has been done, it will probably be better to squash
One special remark is that nothing has been improved in the way .depend
Just a quick note. My take on this is that we'll want to do a global review of what is installed and what might be missing a bit before we call cross-compilers fully supported. It should be simpler than noting down extra files as we see them.
Many thanks for your careful review, @adrien-n. adrien-n (2016/12/25 09:16 -0800):
adrien-n commented on this pull request. > # It is imperative that there is no space after $(NAME_OBJ_FLAG) %.$(DBGO): %.c - $(CC) $(DFLAGS) $(BYTECCDBGCOMPOPTS) -c $(NAME_OBJ_FLAG)$@ $< + $(CC) $(DFLAGS) -c $(NAME_OBJ_FLAG)$@ $< Is $(BYTECCDBGCOMPOPTS) the same as $(BYTECCCOMPOPTS)?
If not, some difference has been introduced here.
Indeed. Actually, BYTECCDBGCOMPOPTS was not used in other places and contained flags which were IMO either not very useful, or not really related to debugging. As far as I can remember, they were not even defined consistently over different ports.
adrien-n (2016/12/25 09:30 -0800):
adrien-n commented on this pull request. > +CFLAGS=-DBOOTSTRAPPING_FLEXLINK +else +CFLAGS= +endif + +# On Windows, OCAML_STDLIB_DIR needs to be defined dynamically + +ifeq "$(UNIX_OR_WIN32)" "win32" +CFLAGS += -DOCAML_STDLIB_DIR='"$(LIBDIR)"' +endif + +CFLAGS += $(IFLEXDIR) $(BYTECCCOMPOPTS) + +DFLAGS=$(CFLAGS) -DDEBUG + +ifneq "$(CCOMPTYPE)" "msvc" As far as I can tell, this changes the behaviour of the non-msvc builds and fixes an issue where non-msvc debug builds didn't have "-g" in $(DFLAGS). Am I right?
adrien-n (2016/12/25 11:07 -0800):
adrien-n commented on this pull request. > @@ -146,3 +153,10 @@ clean :: rm -f $(LIBRARIES) $(PROGRAMS) *.$(O) *.$(A) *.$(SO) rm -f primitives prims.c caml/opnames.h caml/jumptbl.h rm -f caml/version.h + +%.$(O): %.c + $(CC) $(CFLAGS) -c $< + +%.$(DBGO): %.c + $(CC) $(DFLAGS) -c $(OUTPUTOBJ)$@ $< I think the comment "It is imperative that there is no space after $(NAME_OBJ_FLAG)" was quite useful.
Probably. It's just that there are other places in the build system where this comment would be due, too. In the long run, I hope the rules used to compile C source files can be shared over all the subdirectories and then the comment or the macro you describe can be introduced. Is it okay with you to delay this?
However I've always found this brittle and I'm wondering whether a macro ( https://www.gnu.org/software/make/manual/make.html#Call-Function ) would be a better choice: it would only take $(OUTPUTOBJ) to be either "-Fo$(1)" or "-o $(1)" and use would be $(call OUTPUTOBJ,$@).
That's a nice suggestion, thanks. It's worth noting that in the case of '-o' the space is optional, though.
+OBJS=$(COMMONOBJS) $(UNIX_OR_WIN32).$(O) main.$(O) I think you can move $(UNIX_OR_WIN32).$(O) and main.($O) right in $(COMMONOBJS) and at that point you can probably rename $(COMMONOBJS) to $(OBJS) directly.
Very nice suggestion! Thanks a lot! (done)
> @@ -154,6 +159,21 @@ clean :: rm -f primitives prims.c caml/opnames.h caml/jumptbl.h rm -f caml/version.h +libcamlrun.$(A): $(OBJS) + $(call MKLIB,$@, $^) I think you can remove the space before $^. I see where it comes in the current sources from but it's not typical for gnu make code to have a space there.
Ah. To me, this space makes the code a bit more readable but if you think it really should be removed let me know and I will do so.
> @@ -21,13 +21,11 @@ else MAKE_OCAMLRUN=$(MKEXE) -o $(1) $(2) endif -ocamlrun$(EXE): libcamlrun.$(A) prims.$(O) - $(call MAKE_OCAMLRUN,ocamlrun$(EXE),prims.$(O) libcamlrun.$(A) \ - $(call SYSLIB,ws2_32) $(EXTRALIBS)) +ocamlrun$(EXE): prims.$(O) libcamlrun.$(A) + $(call MAKE_OCAMLRUN,$@,$^ $(call SYSLIB,ws2_32) $(EXTRALIBS)) Tangential to your change: I think EXTRALIBS is always empty.
Yeah indeed, I can confirm this.
I don't know if there are actual users of it (who might provide a non-empty value themselves).
Me neither. Can other people comment on this, please? Shall we leave it for the moment and keep its removal for a later, separate PR?
> @@ -159,6 +159,21 @@ clean :: rm -f primitives prims.c caml/opnames.h caml/jumptbl.h rm -f caml/version.h +ifeq "$(UNIX_OR_WIN32)" "win32" I think it will be better to have this block near the top of the file, along the other variables definitions, before the rules.
Good idea, thanks. Done.
> @@ -159,6 +159,21 @@ clean :: rm -f primitives prims.c caml/opnames.h caml/jumptbl.h rm -f caml/version.h +ifeq "$(UNIX_OR_WIN32)" "win32" +LIBS = $(call SYSLIB,ws2_32) $(EXTRALIBS) +ifdef BOOTSTRAPPING_FLEXLINK +MAKE_OCAMLRUN=$(MKEXE_BOOT) +else +MAKE_OCAMLRUN = $(MKEXE) -o $(1) $(2) Is there a reason not to add $(BYTECCLINKOPTS) like in the unix case?
No particular reason, actually, except being conservative...
As far as I see, it's empty in practice for mingw* and msvc* so it wouldn't change anything but it'd be one difference less.
Yeah, I agree. It's just that I didn't dare, thinking that BYTECCLINKOPTS might become non-empty and that, in that case, there could be a problem...
After that I'd be tempted to put MAKE_OCAMLRUN = $(MKEXE) ... before the first conditional and overwrite it in the win32 && BOOTSTRAPPING_FLEXLINK case. This would save quite a few lines and make the block more readable.
I agree, let's see what other people think of the idea of adding BYTECCLINKOPTS...
> @@ -198,3 +198,38 @@ libcamlrun_shared.$(SO): $(PICOBJS) %.$(DBGO): %.c $(CC) $(DFLAGS) -c $(OUTPUTOBJ)$@ $< +ifneq "$(TOOLCHAIN)" "msvc" OK for the code as it is I think. There's a lot I'd like to change here but I guess you too think it's better to leave that for later.
Yes. Which changes did you have in mind, if I may ask? Once again many thanks for your gentle help here!
Squashing should only be used to remove unnecessary back-and-forth, intermediate states that turned out to be wrong and where fixed within the same patchset, from the history. If you found the work easier to build and inspect and review as a series of meaningfully separated commit, there is no reason to squash, and there is reason not to squash: small, atomic commits are much more convenient when going back in time to understand a change, handling conflicts, etc.
@gasche I fear here the right way is somewhere between squashing everything and not squashing at all. See my comments at the beginning of the PR. If you have an opinion about what should be kept and what should be squashed, in the context of this PR, I'm interested.
I think that it is your call to make (note: I'm not sure bisecting from the merge branch will automatically enter merge commits, I think that it bisects at the granularity of merge commits only, and then users have to bisect within the faulty merge). If it was my PR, I would probably try to test the build after each commit, but with 24 commits that could be too long. I think that whatever you choose will be good.
Gabriel Scherer (2016/12/29 06:25 -0800):
I think that it is your call to make (note: I'm not sure bisecting from the merge branch will automatically enter merge commits, I think that it bisects at the granularity of merge commits only, and then users have to bisect within the faulty merge).
If it was my PR, I would probably try to test the build after each commit, but with 24 commits that could be too long.
The real thing is not so much the number of commits, but rather the number of platforms to test. I did some intermediate testing and tried to be very rigourous, both in doing commits and in testing them, but I renounced to being exhaustive. And for the root makefiles this is going to be worth. :)
I think that whatever you choose will be good.
Well, I think if it was just me I'd probably not squash anything and keep the history as it is.
David Allsopp (2016/12/29 06:52 -0800):
Sorry - I meant if all the commits are working on one platform the that's sufficient - the fixes for others in a bisect would either be trivial or can be skipped
Well, does it really make sense to test such a PR on just one platform? Which one would you recommend, then?
Then please consider it "good enough", and go on with your day doing something else that I am sure will also be useful. Your work is already above the unspoken quality standards of the OCaml contribution -- which is fortunate given that the build system is a fiddly area requiring care.
Thanks, @gasche. Re:Changes I'm fine with every solution that will be fine with you. There is already one entry but which can indeed be modified once all this is done, e.g. by listing all the involved PRs. There will be a few changes in the variables present in the installed Makefile.config. How important is this? To which extent should this be docuemnted in Changes?
Well, just my uninformed opinion:
It is not an issue if the change entry is large, because the work itself is large as well.
Many thanks for your insights, @gasche. I think once the build system merge work is over it will probably be wise to go over all the commits once to make sure all the user-visible changes are properly documented. I will do my best to do that but it can't hurt that things are double-checked by others.