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 build systems in the stdlib directory #866

Merged
merged 1 commit into from Nov 9, 2016

Conversation

Projects
None yet
5 participants
@shindere
Contributor

shindere commented Oct 21, 2016

This PR continues the build-systems merging work started in PRs
#762, #764, #785, #788, #811 and #812.

Merge build systems in the stdlib directory
Changes specific to the Unix build system:

  - allopt target: replace invocations to $(MAKE) by prerequisites.

  - installopt-noprof tartget: call ln with the -f option rather than
    removing the destination file before creating the symlink

Changes specific to the Windows build system:

  - allopt target: add the allopt-$(PROFILING) target as a prereq
    Currently, $(PROFILING) is set to noprof in the default Windows
    configuration files (see config/Makefile.*) so this will not change
    anything in practice, except when PROFILING is set to "prof"
    under Windows. From now on this will be honored, whereas it was not,
    before this commit.

  - installopt now also supports installing the library with
    profiling support

Changes affecting both build systems:

  - Declare rules that do not build a file as PHONY.
    This was mostly done in the Unix build system but not in the Windows one.
    However, this commit adds one .PHONY declaration for each
    concerned rule, just above the rule itself, rather than declaring
    several rules PHONY simultaneously. Although this is longer, it
    feels better because that way the information specific to each
    rule is more local.
@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Nov 9, 2016

Contributor

Just rebased on latest trunk. @alainfrisch can you review the code, please?

Contributor

shindere commented Nov 9, 2016

Just rebased on latest trunk. @alainfrisch can you review the code, please?

@gasche

This comment has been minimized.

Show comment
Hide comment
@gasche

gasche Nov 9, 2016

Member

(cc: @dra27, @whitequark (does Adrien Nader have a github account?) who may also be interested in giving an opinion.)

Member

gasche commented Nov 9, 2016

(cc: @dra27, @whitequark (does Adrien Nader have a github account?) who may also be interested in giving an opinion.)

# TODO: see whether there is a way to further merge the rules below
# with those above

This comment has been minimized.

@dra27

dra27 Nov 9, 2016

Contributor

Only with tremendous care - I think more than one of the lines below has been the subject of its own Mantis PR!

@dra27

dra27 Nov 9, 2016

Contributor

Only with tremendous care - I think more than one of the lines below has been the subject of its own Mantis PR!

@dra27

This comment has been minimized.

Show comment
Hide comment
@dra27

dra27 Nov 9, 2016

Contributor

Have you compilation with flexdll built using the submodule (rather than preinstalled)? I of course don't mind doing it, though from a testing perspective, I'd prefer to review/test all these merges at once, even if they're in separate PRs...

Contributor

dra27 commented Nov 9, 2016

Have you compilation with flexdll built using the submodule (rather than preinstalled)? I of course don't mind doing it, though from a testing perspective, I'd prefer to review/test all these merges at once, even if they're in separate PRs...

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Nov 9, 2016

Contributor

David Allsopp (2016/11/09 08:00 -0800):

Have you tested flexdll built using the submodule?

No, not yet. Am I correct that you are talking about boostrapping
flexdll? In that case: is there already a documentation explaining how
this can be tested? As far as I remember it was not obvious how to do it
last time I tried. Moreover flexdll is already installed on the machines
where I do the Windows tests.

@dra27 if you can test the build with the flexdll submodule I'd really
appreciate. This PR is actually the only unmerged one at the moment,
regarding the merge of build systems.

Contributor

shindere commented Nov 9, 2016

David Allsopp (2016/11/09 08:00 -0800):

Have you tested flexdll built using the submodule?

No, not yet. Am I correct that you are talking about boostrapping
flexdll? In that case: is there already a documentation explaining how
this can be tested? As far as I remember it was not obvious how to do it
last time I tried. Moreover flexdll is already installed on the machines
where I do the Windows tests.

@dra27 if you can test the build with the flexdll submodule I'd really
appreciate. This PR is actually the only unmerged one at the moment,
regarding the merge of build systems.

@dra27

This comment has been minimized.

Show comment
Hide comment
@dra27

dra27 Nov 9, 2016

Contributor

No problem - I will try to this evening. Assuming you're using a git clone: git submodule update --init and then make -f Makefile.nt flexdll (you can include world/world.opt after flexdll). It should ignore the system-installed flexlink - though it's a good idea not to have one while testing.

Contributor

dra27 commented Nov 9, 2016

No problem - I will try to this evening. Assuming you're using a git clone: git submodule update --init and then make -f Makefile.nt flexdll (you can include world/world.opt after flexdll). It should ignore the system-installed flexlink - though it's a good idea not to have one while testing.

@whitequark

This comment has been minimized.

Show comment
Hide comment
@whitequark

whitequark Nov 9, 2016

Contributor

My opinion is that this PR set is rather wonderful and is certain to make my life (as a cross-compilation package maintainer) rather easier, even if there are some omissions.

Contributor

whitequark commented Nov 9, 2016

My opinion is that this PR set is rather wonderful and is certain to make my life (as a cross-compilation package maintainer) rather easier, even if there are some omissions.

@shindere

This comment has been minimized.

Show comment
Hide comment
@shindere

shindere Nov 9, 2016

Contributor

Thanks, David, for your prompt responses and your support!

David Allsopp (2016/11/09 08:21 -0800):

No problem - I will try to this evening.

Nice! Thanks!

Assuming you're using a git clone:

Yes, I do.

git submodule update --init and then make -f Makefile.nt flexdll
(you can include world/world.opt after flexdll).

Okay I'll try this tomorrow, thanks!

It should ignore the system-installed flexlink - though it's a good
idea not to have one while testing.

Given that I do my tests on the CI machines, not having flexdll
installed is not really an option. Well it oculd be, if there is the
choice to also test flexdll, but at the moment it's not the case.

What I can do, though, is to remove flexdll from the PATH.

And I'll try this tomorrow.

Contributor

shindere commented Nov 9, 2016

Thanks, David, for your prompt responses and your support!

David Allsopp (2016/11/09 08:21 -0800):

No problem - I will try to this evening.

Nice! Thanks!

Assuming you're using a git clone:

Yes, I do.

git submodule update --init and then make -f Makefile.nt flexdll
(you can include world/world.opt after flexdll).

Okay I'll try this tomorrow, thanks!

It should ignore the system-installed flexlink - though it's a good
idea not to have one while testing.

Given that I do my tests on the CI machines, not having flexdll
installed is not really an option. Well it oculd be, if there is the
choice to also test flexdll, but at the moment it's not the case.

What I can do, though, is to remove flexdll from the PATH.

And I'll try this tomorrow.

@dra27

This comment has been minimized.

Show comment
Hide comment
@dra27

dra27 Nov 9, 2016

Contributor

Removing from PATH is safely equivalent to not having it - there's nothing in the build system which ever try to search for it.

Contributor

dra27 commented Nov 9, 2016

Removing from PATH is safely equivalent to not having it - there's nothing in the build system which ever try to search for it.

@dra27

This comment has been minimized.

Show comment
Hide comment
@dra27

dra27 Nov 9, 2016

Contributor

Just tried it with msvc x86 and bootstrapped flexdll and everything seems fine!

Contributor

dra27 commented Nov 9, 2016

Just tried it with msvc x86 and bootstrapped flexdll and everything seems fine!

@gasche

This comment has been minimized.

Show comment
Hide comment
@gasche

gasche Nov 9, 2016

Member

@dra27 Thanks for the testing! Feel free to merge if you think this is good.

Member

gasche commented Nov 9, 2016

@dra27 Thanks for the testing! Feel free to merge if you think this is good.

@adrien-n

Nothing obviously wrong stood out. The diff seems more difficult to read than it ought to be because git doesn't seem to notice this is a move but I assume you've simply moved the content of Makefile.nt around and wrapped it in a conditional.

echo '#!$(BINDIR)/ocamlrun'$$suff > camlheader$$suff && \
echo '#!$(TARGET_BINDIR)/ocamlrun'$$suff >target_camlheader$$suff; \
done && \
echo '#!' | tr -d '\012' > camlheader_ur;

This comment has been minimized.

@adrien-n

adrien-n Nov 9, 2016

Contributor

This is most probably for another patchset:

printf "#!" > camlheader_ur

would be much cleaner. I'm not sure we can get into this branch on platforms with \r\n end-of-lines however.

@adrien-n

adrien-n Nov 9, 2016

Contributor

This is most probably for another patchset:

printf "#!" > camlheader_ur

would be much cleaner. I'm not sure we can get into this branch on platforms with \r\n end-of-lines however.

@dra27 dra27 merged commit db12391 into ocaml:trunk Nov 9, 2016

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@shindere shindere deleted the shindere:merge-stdlib-makefiles branch Nov 10, 2016

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

Merge build systems in the stdlib directory (#866)
Changes specific to the Unix build system:

  - allopt target: replace invocations to $(MAKE) by prerequisites.

  - installopt-noprof tartget: call ln with the -f option rather than
    removing the destination file before creating the symlink

Changes specific to the Windows build system:

  - allopt target: add the allopt-$(PROFILING) target as a prereq
    Currently, $(PROFILING) is set to noprof in the default Windows
    configuration files (see config/Makefile.*) so this will not change
    anything in practice, except when PROFILING is set to "prof"
    under Windows. From now on this will be honored, whereas it was not,
    before this commit.

  - installopt now also supports installing the library with
    profiling support

Changes affecting both build systems:

  - Declare rules that do not build a file as PHONY.
    This was mostly done in the Unix build system but not in the Windows one.
    However, this commit adds one .PHONY declaration for each
    concerned rule, just above the rule itself, rather than declaring
    several rules PHONY simultaneously. Although this is longer, it
    feels better because that way the information specific to each
    rule is more local.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment