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

build: adding config.gypi dep to addons/.buildstamp #7893

Closed
wants to merge 1 commit into from

Conversation

danbev
Copy link
Contributor

@danbev danbev commented Jul 27, 2016

Checklist
  • make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

build

Description of change

Currently the build-addons target is called as part of the
test target, and it has test/addons/.buildstamp as a dependency.
When running ./configure --debug and later switching/
updating branches you can be in a situation where the config.gypi
files in the addons build directories are using an incorrect
value for default_configuration. Currently this can happen and you
will get test errors as there are a few test that depend on the
value of default_configuration to be Release. When this happens
it might not be obvious to someone new to the project (like me)
to correct this state. This commit attempts to make it easier
to fix this.

The suggestion here is if you find yourself in the above situation
the the following steps would be preformed:

1) make clean
2) ./configure
3) make -j4 test

The target distclean also calls clean-addons so that could be used
instead of clean in the above example. Also clean-addons could be
called directly if required.

This commit is related to #7860. Please see the dicussion in that
issue regarding the test using hard-coded paths.

@nodejs-github-bot nodejs-github-bot added the build Issues and PRs related to build files or the CI. label Jul 27, 2016
@@ -92,6 +92,7 @@ clean:
-rm -rf node_modules
@if [ -d deps/icu ]; then echo deleting deps/icu; rm -rf deps/icu; fi
-rm -f test.tap
$(MAKE) clean-addons
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can add these as prerequisites on the targets themselves, e.g. clean: clean-addons

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problems, I've added them as dependencies now.

@addaleax
Copy link
Member

addaleax commented Jul 27, 2016

CI: https://ci.nodejs.org/job/node-test-commit/4286/

Btw, it’s generally appreciated when references to Github issues/PRs in the commit message use the full URL, so that it’s easier to e.g. disambiguate from the old (https://github.com/nodejs/node-v0.x-archive) issue tracker and the link can be opened when viewing from the terminal (and probably a few other reasons as well).

Otherwise, this LGTM if @bnoordhuis and CI are happy, thanks!

@danbev
Copy link
Contributor Author

danbev commented Jul 27, 2016

Btw, it’s generally appreciated when references to Github issues/PRs in the commit message use the full URL, so that it’s easier to e.g. disambiguate from the old (https://github.com/nodejs/node-v0.x-archive) issue tracker and the link can be opened when viewing from the terminal (and probably a few other reasons as well).

Ah good to know, thanks. I'll rebase later and squash the commits, and also update the original commit message with the full URL once CI has completed (and allow time for anyone else to comment).

@jasnell
Copy link
Member

jasnell commented Jul 29, 2016

LGTM but let's definitely give @bnoordhuis a chance to review also.

@bnoordhuis
Copy link
Member

The rule name is slightly misleading because it doesn't actually clean. Would this work?

diff --git a/Makefile b/Makefile
index c827968..8a232c0 100644
--- a/Makefile
+++ b/Makefile
@@ -150,7 +150,8 @@ ADDONS_BINDING_SOURCES := \
 # Implicitly depends on $(NODE_EXE), see the build-addons rule for rationale.
 # Depends on node-gyp package.json so that build-addons is (re)executed when
 # node-gyp is updated as part of an npm update.
-test/addons/.buildstamp: deps/npm/node_modules/node-gyp/package.json \
+test/addons/.buildstamp: config.gypi \
+       deps/npm/node_modules/node-gyp/package.json \
        $(ADDONS_BINDING_GYPS) $(ADDONS_BINDING_SOURCES) \
        deps/uv/include/*.h deps/v8/include/*.h \
        src/node.h src/node_buffer.h src/node_object_wrap.h \

Currently the build-addons target is called as part of the
test target, and it has test/addons/.buildstamp as a dependency.
When running ./configure --debug and later switching/
updating branches you can be in a situation where the config.gypi
files in the addons build directories are using an incorrect
value for default_configuration. Currently this can happen and you
will get test errors as there are a few test that depend on the
value of default_configuration to be Release.

Ben Noordhuis provided the solution for this by adding a dependency to
config.gypi, which is generated when running ./configure, and will
correct this situation.

This commit is related to nodejs#7860. Please see the dicussion in that
issue regarding the test using hard-coded paths.
@danbev
Copy link
Contributor Author

danbev commented Jul 30, 2016

The rule name is slightly misleading because it doesn't actually clean. Would this work?

That works and is a much better solution!

I'll rebase and remove the previous commits, and please feel free to change the author of this as you did all the work :) Thanks

@danbev danbev force-pushed the clean-test-addons branch from 80416d0 to 95309d8 Compare July 30, 2016 10:17
@bnoordhuis
Copy link
Member

LGTM. I don't mind the authorship; if you go through the motions of filing a PR, you are welcome to the commit. :-)

@jasnell jasnell changed the title build: adding a clean-addons target to Makefile build: adding config.gypi dep to addons/.buildstamp Aug 1, 2016
@jasnell
Copy link
Member

jasnell commented Aug 1, 2016

Updated the name of the PR to match the commit. LGTM!

jasnell pushed a commit that referenced this pull request Aug 1, 2016
Currently the build-addons target is called as part of the
test target, and it has test/addons/.buildstamp as a dependency.
When running ./configure --debug and later switching/
updating branches you can be in a situation where the config.gypi
files in the addons build directories are using an incorrect
value for default_configuration. Currently this can happen and you
will get test errors as there are a few test that depend on the
value of default_configuration to be Release.

Ben Noordhuis provided the solution for this by adding a dependency to
config.gypi, which is generated when running ./configure, and will
correct this situation.

This commit is related to #7860. Please see the dicussion in that
issue regarding the test using hard-coded paths.

PR-URL: #7893
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
@jasnell
Copy link
Member

jasnell commented Aug 1, 2016

Landed in eeaff74! thank you!

@jasnell jasnell closed this Aug 1, 2016
@cjihrig cjihrig mentioned this pull request Aug 8, 2016
cjihrig pushed a commit that referenced this pull request Aug 10, 2016
Currently the build-addons target is called as part of the
test target, and it has test/addons/.buildstamp as a dependency.
When running ./configure --debug and later switching/
updating branches you can be in a situation where the config.gypi
files in the addons build directories are using an incorrect
value for default_configuration. Currently this can happen and you
will get test errors as there are a few test that depend on the
value of default_configuration to be Release.

Ben Noordhuis provided the solution for this by adding a dependency to
config.gypi, which is generated when running ./configure, and will
correct this situation.

This commit is related to #7860. Please see the dicussion in that
issue regarding the test using hard-coded paths.

PR-URL: #7893
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
@cjihrig cjihrig mentioned this pull request Aug 11, 2016
@danbev danbev deleted the clean-test-addons branch September 7, 2016 08:30
@MylesBorins
Copy link
Contributor

do people think this should be backported?

@bnoordhuis
Copy link
Member

Yes.

@MylesBorins
Copy link
Contributor

it is going to need a manual backport, @bnoordhuis or @danbev would you be willing to help with that?

@danbev
Copy link
Contributor Author

danbev commented Sep 30, 2016

it is going to need a manual backport, @bnoordhuis or @danbev would you be willing to help with that?

I'd be happy to help. I don't know how much time I'll have this weekend though, but should be able to take a look on Monday-Tuesday next week if that is soon enough?

@bnoordhuis
Copy link
Member

That's fine, there's no rush.

@danbev
Copy link
Contributor Author

danbev commented Oct 3, 2016

@thealphanerd Could you point me which branch this should be applied?
Would this simply be a matter of creating a pull request against that branch? Thanks

@MylesBorins
Copy link
Contributor

@danbev v4.x-staging. Indeed just make a PR against it 👍🏽

@danbev
Copy link
Contributor Author

danbev commented Oct 3, 2016

@thealphanerd Thanks for your help! I've created this PR for this now.

danbev added a commit to danbev/node that referenced this pull request Oct 6, 2016
Currently the build-addons target is called as part of the
test target, and it has test/addons/.buildstamp as a dependency.
When running ./configure --debug and later switching/
updating branches you can be in a situation where the config.gypi
files in the addons build directories are using an incorrect
value for default_configuration. Currently this can happen and you
will get test errors as there are a few test that depend on the
value of default_configuration to be Release.

Ben Noordhuis provided the solution for this by adding a dependency to
config.gypi, which is generated when running ./configure, and will
correct this situation.

This commit is related to nodejs#7860. Please see the dicussion in that
issue regarding the test using hard-coded paths.

Ref: nodejs#7893
MylesBorins pushed a commit that referenced this pull request Oct 7, 2016
Currently the build-addons target is called as part of the
test target, and it has test/addons/.buildstamp as a dependency.
When running ./configure --debug and later switching/
updating branches you can be in a situation where the config.gypi
files in the addons build directories are using an incorrect
value for default_configuration. Currently this can happen and you
will get test errors as there are a few test that depend on the
value of default_configuration to be Release.

Ben Noordhuis provided the solution for this by adding a dependency to
config.gypi, which is generated when running ./configure, and will
correct this situation.

This commit is related to #7860. Please see the dicussion in that
issue regarding the test using hard-coded paths.

Ref: #8905
PR-URL: #7893
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
MylesBorins pushed a commit that referenced this pull request Oct 10, 2016
Currently the build-addons target is called as part of the
test target, and it has test/addons/.buildstamp as a dependency.
When running ./configure --debug and later switching/
updating branches you can be in a situation where the config.gypi
files in the addons build directories are using an incorrect
value for default_configuration. Currently this can happen and you
will get test errors as there are a few test that depend on the
value of default_configuration to be Release.

Ben Noordhuis provided the solution for this by adding a dependency to
config.gypi, which is generated when running ./configure, and will
correct this situation.

This commit is related to #7860. Please see the dicussion in that
issue regarding the test using hard-coded paths.

Ref: #8905
PR-URL: #7893
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
rvagg pushed a commit that referenced this pull request Oct 18, 2016
Currently the build-addons target is called as part of the
test target, and it has test/addons/.buildstamp as a dependency.
When running ./configure --debug and later switching/
updating branches you can be in a situation where the config.gypi
files in the addons build directories are using an incorrect
value for default_configuration. Currently this can happen and you
will get test errors as there are a few test that depend on the
value of default_configuration to be Release.

Ben Noordhuis provided the solution for this by adding a dependency to
config.gypi, which is generated when running ./configure, and will
correct this situation.

This commit is related to #7860. Please see the dicussion in that
issue regarding the test using hard-coded paths.

Ref: #8905
PR-URL: #7893
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
MylesBorins pushed a commit that referenced this pull request Oct 26, 2016
Currently the build-addons target is called as part of the
test target, and it has test/addons/.buildstamp as a dependency.
When running ./configure --debug and later switching/
updating branches you can be in a situation where the config.gypi
files in the addons build directories are using an incorrect
value for default_configuration. Currently this can happen and you
will get test errors as there are a few test that depend on the
value of default_configuration to be Release.

Ben Noordhuis provided the solution for this by adding a dependency to
config.gypi, which is generated when running ./configure, and will
correct this situation.

This commit is related to #7860. Please see the dicussion in that
issue regarding the test using hard-coded paths.

Ref: #8905
PR-URL: #7893
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Oct 26, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants