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

Merge Unix and Windows build systems in the asmrun directory #941

Merged
merged 5 commits into from Dec 20, 2016

Conversation

Projects
None yet
6 participants
@shindere
Contributor

shindere commented Nov 29, 2016

Cc @adrien-n @alainfrisch @dra27 @whitequark
(Is there somebody else who could / should be Cc'ed?)

For the Makefiles in asmrun themselves the diff seems difficult to read
so reviewers may prefere to read the new asmrun/Makefile directly, given
that asmrun/Makefile.nt just includes the asmrun/Makefile and
asmrun/Makefile.shared has been removed.

It is worth noting that, for the moment, CFLAGS contains -g -O0 as it
did before. Shouldn't these two options be in DFLAGS rather than CFLAGS?

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Nov 29, 2016

Contributor

I think it's quite helpful for users if the runtime is always built with -g.

I seem to remember that the -O0 is overridden in some unpleasant way using an additional -O2 flag propagated from configure, but I don't remember the details offhand. I agree that this flag should probably not be there (and if -O0 is required as a preventative measure against wrong optimisation then perhaps it should be propagated as the default from configure).

Contributor

mshinwell commented Nov 29, 2016

I think it's quite helpful for users if the runtime is always built with -g.

I seem to remember that the -O0 is overridden in some unpleasant way using an additional -O2 flag propagated from configure, but I don't remember the details offhand. I agree that this flag should probably not be there (and if -O0 is required as a preventative measure against wrong optimisation then perhaps it should be propagated as the default from configure).

@adrien-n

(comment slightly reworded)

In addition to what is written below, I've noticed that "testsuite/tests/lib-dynlink-native/Makefile" refers to SHARED so you'll have to update it.

Show outdated Hide outdated asmrun/Makefile
$(ARCMD) rc libasmrun.a $(OBJS)
$(RANLIB) libasmrun.a
ASPPFLAGS = -DSYS_$(SYSTEM)
ifeq "$(UNIX_OR_WIN32)" "unix"

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

I think we can drop the conditional and pass the define to all builds. I believe the only reason it is not currently passed is the lack of a need rather than the need to avoid it.

@adrien-n

adrien-n Dec 2, 2016

Contributor

I think we can drop the conditional and pass the define to all builds. I believe the only reason it is not currently passed is the lack of a need rather than the need to avoid it.

Show outdated Hide outdated asmrun/Makefile
all: libasmrun.a all-$(RUNTIMED) all-$(PROFILINGTARGET) all-$(SHARED)
FLAGS=\
-I../byterun $(IFLEXDIR) \
-DNATIVE_CODE -DTARGET_$(ARCH) -DMODEL_$(MODEL) -DSYS_$(SYSTEM) \

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

I'm tempted to say that the sharing with ASPPFLAGS should be increased but I would prefer even more that they are provided through config/m.h instead. It's probably better to not add such changes now however since there are other things that are more important.

@adrien-n

adrien-n Dec 2, 2016

Contributor

I'm tempted to say that the sharing with ASPPFLAGS should be increased but I would prefer even more that they are provided through config/m.h instead. It's probably better to not add such changes now however since there are other things that are more important.

Show outdated Hide outdated asmrun/Makefile
all-noruntimed:
.PHONY: all-noruntimed
ifeq ($(TOOLCHAIN),msvc)

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

Can you make that consistent with other "ifeq" conditionals in the file (i.e. with arguments separated by spaces)? (I understand this is moved from the .nt part)

@adrien-n

adrien-n Dec 2, 2016

Contributor

Can you make that consistent with other "ifeq" conditionals in the file (i.e. with arguments separated by spaces)? (I understand this is moved from the .nt part)

rm -f libasmrund.a
$(ARCMD) rc libasmrund.a $(DOBJS)
$(RANLIB) libasmrund.a
OBJS=$(COBJS) $(ASMOBJS)

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

The lines that follow feel like they duplicate code but I support what you've done, i.e. longer but simpler code.

@adrien-n

adrien-n Dec 2, 2016

Contributor

The lines that follow feel like they duplicate code but I support what you've done, i.e. longer but simpler code.

Show outdated Hide outdated asmrun/Makefile
$(LINKEDFILES): %.c: ../byterun/%.c
ln -s ../byterun/$*.c $*.c
$(LN) $< $@
# $(LN) ../byterun/$*.c $*.c

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

Is this comment intentional? It helps parse the rule however but also made me wonder if some functionality had been disabled. A short comment explaining the .c files needed are the same as the ones in ../byterun would probably help understand this bit better (I regularly forget it exists).

@adrien-n

adrien-n Dec 2, 2016

Contributor

Is this comment intentional? It helps parse the rule however but also made me wonder if some functionality had been disabled. A short comment explaining the .c files needed are the same as the ones in ../byterun would probably help understand this bit better (I regularly forget it exists).

Show outdated Hide outdated asmrun/Makefile
.PHONY: clean
clean:
rm -f $(LINKEDFILES)
rm -f *.$(O) *.$(A) *.$(SO) *~

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

'*~' should be dropped from the list (I noticed it was there before but nonetheless, that's bad practice).

@adrien-n

adrien-n Dec 2, 2016

Contributor

'*~' should be dropped from the list (I noticed it was there before but nonetheless, that's bad practice).

ifeq "$(UNIX_OR_WIN32)" "win32"
.depend.nt: .depend
sed -e 's/\.o/.$(O)/g' .depend > .depend.nt

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

You can drop the 'g' in the sed command since there is only one match per line and that will make it consistent with the sed commands above (which only handle one match per line).

@adrien-n

adrien-n Dec 2, 2016

Contributor

You can drop the 'g' in the sed command since there is only one match per line and that will make it consistent with the sed commands above (which only handle one match per line).

depend: $(COBJS:.o=.c) ${LINKEDFILES}
ifneq "$(TOOLCHAIN)" "msvc"
.PHONY: depend
depend: $(COBJS:.$(O)=.c) $(LINKEDFILES)
$(CC) -MM $(FLAGS) *.c > .depend
$(CC) -MM $(FLAGS) -DPROFILING *.c | sed -e 's/\.o/.p.o/' >> .depend

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

The regex should probably be improved in a separate commit: '.o' could easily lead to a false positive. '.o:' would already be a clear improvement I think. Moreover it could be rewritten as 's/.o:/.p&/' ('\0' is a gnu-ism unfortunately; that doesn't mean I've checked my example works on BSD however).

@adrien-n

adrien-n Dec 2, 2016

Contributor

The regex should probably be improved in a separate commit: '.o' could easily lead to a false positive. '.o:' would already be a clear improvement I think. Moreover it could be rewritten as 's/.o:/.p&/' ('\0' is a gnu-ism unfortunately; that doesn't mean I've checked my example works on BSD however).

This comment has been minimized.

@damiendoligez

damiendoligez Dec 20, 2016

Member

Note that it's not .o but \.o that is matched, and only the first one one the line. As for using & I think it would only make it harder to read.

Edit -- In fact I misread your comment because GitHub seems to be doing funny things with backslashes.

@damiendoligez

damiendoligez Dec 20, 2016

Member

Note that it's not .o but \.o that is matched, and only the first one one the line. As for using & I think it would only make it harder to read.

Edit -- In fact I misread your comment because GitHub seems to be doing funny things with backslashes.

$(call MKLIB,libasmrun.$(A), $(OBJS))
i386nt.obj: i386nt.asm
$(ASM)i386nt.obj i386nt.asm

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

This indicates that this was probably written with msvc's command-line interface in mind. I'm not sure your new invocations are compatible with it however. To give you an idea on the possible matter:

config/Makefile.mingw64:ASM=$(TOOLPREF)as
config/Makefile.msvc64:ASM=ml64 -nologo -Cp -c -Fo
@adrien-n

adrien-n Dec 2, 2016

Contributor

This indicates that this was probably written with msvc's command-line interface in mind. I'm not sure your new invocations are compatible with it however. To give you an idea on the possible matter:

config/Makefile.mingw64:ASM=$(TOOLPREF)as
config/Makefile.msvc64:ASM=ml64 -nologo -Cp -c -Fo
ifeq "$(UNIX_OR_WIN32)" "win32"

This comment has been minimized.

@adrien-n

adrien-n Dec 2, 2016

Contributor

Does anyone know if MSVC is usable to generate the .depend files? If so it would be possible to drop this completely simply by using "$(O)" above.

I would at least change the test to be on $(TOOLCHAIN) instead and I would name the file '.depend.msvc' instead.

@adrien-n

adrien-n Dec 2, 2016

Contributor

Does anyone know if MSVC is usable to generate the .depend files? If so it would be possible to drop this completely simply by using "$(O)" above.

I would at least change the test to be on $(TOOLCHAIN) instead and I would name the file '.depend.msvc' instead.

@adrien-n

This comment has been minimized.

Show comment
Hide comment
@adrien-n

adrien-n Dec 2, 2016

Contributor

Also, I'm not sure the runtime should be built with -O0 if -O2 brings a performance improvement because while it makes debugging crashes slightly more difficult, it usually doesn't make it impossible. Moreover the runtime is fairly stable nowadays.

That said, if the topic hasn't been discussed yet, it should be done in a /separate/ discussion and the current behaviour should be kept.

Contributor

adrien-n commented Dec 2, 2016

Also, I'm not sure the runtime should be built with -O0 if -O2 brings a performance improvement because while it makes debugging crashes slightly more difficult, it usually doesn't make it impossible. Moreover the runtime is fairly stable nowadays.

That said, if the topic hasn't been discussed yet, it should be done in a /separate/ discussion and the current behaviour should be kept.

@xavierleroy

This comment has been minimized.

Show comment
Hide comment
@xavierleroy

xavierleroy Dec 2, 2016

Contributor

The -O0 flag makes no sense because we want the highest safe optimization level, as determined by the configure script. FWIW, -O0 was introduced by @mshinwell in a Spacetime-related commit. This shouldn't have passed review.

Contributor

xavierleroy commented Dec 2, 2016

The -O0 flag makes no sense because we want the highest safe optimization level, as determined by the configure script. FWIW, -O0 was introduced by @mshinwell in a Spacetime-related commit. This shouldn't have passed review.

@xavierleroy

This comment has been minimized.

Show comment
Hide comment
@xavierleroy

xavierleroy Dec 2, 2016

Contributor

The -g flag on non-debug builds might be OK if we're sure it doesn't degrade optimizations. (Remember that many OCaml programs spend 30% of their time in the garbage collector and memory allocator. You want very good optimization for the runtime system.) But -runtime-variant d is your true friend if you need debugging within the runtime system, as it also turns in copious assertions and internal checks.

Contributor

xavierleroy commented Dec 2, 2016

The -g flag on non-debug builds might be OK if we're sure it doesn't degrade optimizations. (Remember that many OCaml programs spend 30% of their time in the garbage collector and memory allocator. You want very good optimization for the runtime system.) But -runtime-variant d is your true friend if you need debugging within the runtime system, as it also turns in copious assertions and internal checks.

@adrien-n

This comment has been minimized.

Show comment
Hide comment
@adrien-n

adrien-n Dec 2, 2016

Contributor
Contributor

adrien-n commented Dec 2, 2016

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 7, 2016

Contributor
Contributor

shindere commented Dec 7, 2016

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 8, 2016

Contributor
Contributor

shindere commented Dec 8, 2016

@xavierleroy

This comment has been minimized.

Show comment
Hide comment
@xavierleroy

xavierleroy Dec 9, 2016

Contributor

A trick that I found useful in other projects:

It is possible to have only one .depend file that works with MSVC as well as with Unix-style compilers: just generate it so that it contains .$(O) but neither .o nor .obj.

In the sed command that massages the output of gcc -MM, just replace .o by .$$(O) (note the double $ so that make doesn't expand $(O) into .o or .obj before running sed).

Contributor

xavierleroy commented Dec 9, 2016

A trick that I found useful in other projects:

It is possible to have only one .depend file that works with MSVC as well as with Unix-style compilers: just generate it so that it contains .$(O) but neither .o nor .obj.

In the sed command that massages the output of gcc -MM, just replace .o by .$$(O) (note the double $ so that make doesn't expand $(O) into .o or .obj before running sed).

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 9, 2016

Contributor
Contributor

shindere commented Dec 9, 2016

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Dec 14, 2016

Contributor

@shindere There is a significant regression on trunk at the moment (compared to 4.04) because the order of -O0 and -O2 options has changed, which I think is causing -O0 optimisation to be applied to the runtime, instead of -O2. Maybe you've fixed this already.

(As an aside there may be another smaller performance regression which we will investigate once this one has been fixed.)

Contributor

mshinwell commented Dec 14, 2016

@shindere There is a significant regression on trunk at the moment (compared to 4.04) because the order of -O0 and -O2 options has changed, which I think is causing -O0 optimisation to be applied to the runtime, instead of -O2. Maybe you've fixed this already.

(As an aside there may be another smaller performance regression which we will investigate once this one has been fixed.)

@mshinwell

This comment has been minimized.

Show comment
Hide comment
@mshinwell

mshinwell Dec 14, 2016

Contributor

(It looks like this has already been fixed; apologies if this mistakenly came from the Spacetime merge, although it had no effect in 4.04.)

Contributor

mshinwell commented Dec 14, 2016

(It looks like this has already been fixed; apologies if this mistakenly came from the Spacetime merge, although it had no effect in 4.04.)

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 14, 2016

Contributor
Contributor

shindere commented Dec 14, 2016

@adrien-n

This comment has been minimized.

Show comment
Hide comment
@adrien-n

adrien-n Dec 15, 2016

Contributor
Contributor

adrien-n commented Dec 15, 2016

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 16, 2016

Contributor
Contributor

shindere commented Dec 16, 2016

@xavierleroy

This comment has been minimized.

Show comment
Hide comment
@xavierleroy

xavierleroy Dec 18, 2016

Contributor

It is a nice idea, indeed. But as I understand it, it still requires gcc to generate dependencies. So it will indeed simplify the build system because it lets one generate one .depend file that works for all ports, but it won't let us generate dependencies dynamically on msvc, which I find a pity.

Let me be very clear here: I don't want msvc to generate the .depend files. Those files are under version control and are part of the distribution. This implies they should be generated by a tool that we trust and that produces reproducible output (to minimize conflicts and commits). I don't trust msvc to generate those files, since apparently it relies on undocumented or semi-documented features of msvc. And I'm positive that msvc would generate output very different from gcc, causing version control hell. So, please forget about that.

Contributor

xavierleroy commented Dec 18, 2016

It is a nice idea, indeed. But as I understand it, it still requires gcc to generate dependencies. So it will indeed simplify the build system because it lets one generate one .depend file that works for all ports, but it won't let us generate dependencies dynamically on msvc, which I find a pity.

Let me be very clear here: I don't want msvc to generate the .depend files. Those files are under version control and are part of the distribution. This implies they should be generated by a tool that we trust and that produces reproducible output (to minimize conflicts and commits). I don't trust msvc to generate those files, since apparently it relies on undocumented or semi-documented features of msvc. And I'm positive that msvc would generate output very different from gcc, causing version control hell. So, please forget about that.

else
PROFILINGTARGET = noprof
LN = ln -s
endif

This comment has been minimized.

@dra27

dra27 Dec 19, 2016

Contributor

A future note for when you get to autoconf: https://github.com/dra27/dose/blob/master/configure.ac#L261-L269

@dra27

dra27 Dec 19, 2016

Contributor

A future note for when you get to autoconf: https://github.com/dra27/dose/blob/master/configure.ac#L261-L269

@dra27

This comment has been minimized.

Show comment
Hide comment
@dra27

dra27 Dec 19, 2016

Contributor

I've just compiled this branch on msvc/msvc64/mingw/mingw64 using FlexDLL bootstrap and FLAMBDA (just to try to test a combination which may not have been looked at so far). A few questions, probably mostly from my ignorance:

  • libasmrun_shared.s.$(O) is now built - what is this for and potentially shouldn't its extension be .dll?
  • I notice - independent to this GPR - that using _pic for -runtime-variant doesn't appear to documented in the manual... if that's incorrect someone (perhaps me!) should raise a PR...
  • But relevantly, what do the new PIC objects add for the Windows builds, especially on x86 (that may just be my architectural ignorance)
  • If PIC is useful here, are there any tests for it?
Contributor

dra27 commented Dec 19, 2016

I've just compiled this branch on msvc/msvc64/mingw/mingw64 using FlexDLL bootstrap and FLAMBDA (just to try to test a combination which may not have been looked at so far). A few questions, probably mostly from my ignorance:

  • libasmrun_shared.s.$(O) is now built - what is this for and potentially shouldn't its extension be .dll?
  • I notice - independent to this GPR - that using _pic for -runtime-variant doesn't appear to documented in the manual... if that's incorrect someone (perhaps me!) should raise a PR...
  • But relevantly, what do the new PIC objects add for the Windows builds, especially on x86 (that may just be my architectural ignorance)
  • If PIC is useful here, are there any tests for it?
@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 19, 2016

Contributor
Contributor

shindere commented Dec 19, 2016

@dra27

This comment has been minimized.

Show comment
Hide comment
@dra27

dra27 Dec 19, 2016

Contributor

Notwithstanding Alain wishing to comment and assuming that Adrien is happy too, this looks good to go to me.

Contributor

dra27 commented Dec 19, 2016

Notwithstanding Alain wishing to comment and assuming that Adrien is happy too, this looks good to go to me.

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 19, 2016

Contributor
Contributor

shindere commented Dec 19, 2016

shindere added some commits Oct 21, 2016

Merge Unix and Windows build systems in the asmrun directory
Changes in make variables:

  - Removal of the SHARED make variable, which had the same
    semantics than SUPPORTS_SHARED_LIBRARIES, the later having values true
    and false while the former had values shared and noshared.
    (SHARED was not defined on Windows)
  - RUNTIMED now takes values true and false rather than runtimed and
    noruntimed
Build PIC libraries only under Unix
This makes things closer to what they were before, since PIC objects
were not built for Windows.
@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 20, 2016

Contributor

Just rebased.

Contributor

shindere commented Dec 20, 2016

Just rebased.

@dra27

This comment has been minimized.

Show comment
Hide comment
@dra27

dra27 Dec 20, 2016

Contributor

I see that Damien has been doing some work on the CI - has this been through precheck, just to check for any subtleties on other arches?

Contributor

dra27 commented Dec 20, 2016

I see that Damien has been doing some work on the CI - has this been through precheck, just to check for any subtleties on other arches?

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 20, 2016

Contributor
Contributor

shindere commented Dec 20, 2016

@dra27

This comment has been minimized.

Show comment
Hide comment
@dra27

dra27 Dec 20, 2016

Contributor

OK - if Damien's changes aren't complete (or aren't yet copied to precheck), it's possible that you'll see complete failure on all 6 Windows ports, but I can always test them again manually!

Contributor

dra27 commented Dec 20, 2016

OK - if Damien's changes aren't complete (or aren't yet copied to precheck), it's possible that you'll see complete failure on all 6 Windows ports, but I can always test them again manually!

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 20, 2016

Contributor
Contributor

shindere commented Dec 20, 2016

@damiendoligez

I've reviewed and it's good to go.

Show outdated Hide outdated configure
@@ -2182,7 +2177,7 @@ else
inf "Source-level replay debugger: not supported"
fi
if test "$debugruntime" = "runtimed"; then
if test $debugruntime; then

This comment has been minimized.

@damiendoligez

damiendoligez Dec 20, 2016

Member

The call to test is redundant here because true and false are shell commands.

@damiendoligez

damiendoligez Dec 20, 2016

Member

The call to test is redundant here because true and false are shell commands.

@damiendoligez damiendoligez merged commit 68ad1bb into ocaml:trunk Dec 20, 2016

0 of 2 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details

@shindere shindere deleted the shindere:merge-asmrun-makefiles branch Dec 21, 2016

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Dec 22, 2016

Contributor
Contributor

shindere commented Dec 22, 2016

@dra27

This comment has been minimized.

Show comment
Hide comment
@dra27

dra27 Dec 22, 2016

Contributor

It's got even more interesting since the next version of Windows 10 allows developers to use symlinks without elevating!

Contributor

dra27 commented Dec 22, 2016

It's got even more interesting since the next version of Windows 10 allows developers to use symlinks without elevating!

shindere added a commit to shindere/ocaml that referenced this pull request Feb 16, 2017

shindere added a commit to shindere/ocaml that referenced this pull request Feb 17, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
ocaml#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

shindere added a commit to shindere/ocaml that referenced this pull request Feb 17, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
ocaml#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

shindere added a commit to shindere/ocaml that referenced this pull request Feb 21, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
ocaml#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

shindere added a commit to shindere/ocaml that referenced this pull request Mar 1, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
ocaml#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

shindere added a commit to shindere/ocaml that referenced this pull request Mar 3, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
ocaml#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

shindere added a commit to shindere/ocaml that referenced this pull request Mar 7, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
ocaml#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

shindere added a commit to shindere/ocaml that referenced this pull request Mar 7, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
ocaml#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

shindere added a commit to shindere/ocaml that referenced this pull request Mar 8, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
ocaml#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

shindere added a commit to shindere/ocaml that referenced this pull request Mar 9, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
ocaml#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

damiendoligez added a commit that referenced this pull request Mar 9, 2017

Make .depend files generated for C sources more portable
This implements a suggestion provided by @xavierleroy in
#941 (comment)

Before this commit, the dependencies of the win32unix C files were not
taken into account at all. This commit fixes this, too.

camlspotter pushed a commit to camlspotter/ocaml that referenced this pull request Oct 17, 2017

Merge Unix and Windows build systems in the asmrun directory (#941)
* Merge Unix and Windows build systems in the asmrun directory

Changes in make variables:

  - Removal of the SHARED make variable, which had the same
    semantics than SUPPORTS_SHARED_LIBRARIES, the later having values true
    and false while the former had values shared and noshared.
    (SHARED was not defined on Windows)
  - RUNTIMED now takes values true and false rather than runtimed and
    noruntimed

* Do not use -O0 in asmrun's Makefile

* Add /asmrun/win32.c to .gitignore

* Build PIC libraries only under Unix

This makes things closer to what they were before, since PIC objects
were not built for Windows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment