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: fix config.gypi target #9053

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@danbev
Member

danbev commented Oct 12, 2016

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

build

Description of change

The config.gypi target has a recipe that uses the control function error
to report if the config.gypi file is missing or if it is stale (the
configure file was updated which is a prerequisite of this rule).

GNU make has two phases, immediate and deferred. During the first phase
it will expand any variables or functions as the makefile is parsed.
The recipe in this case is a shell if statement, which is a deferred
construct. But the control function $(error) is an immediate construct
which will cause the makefile processing to stop during the first phase
of the Make process.

If I understand this correctly the only possible outcome of this rule is
the "Stale config.gypi, please re-run ./configure" message which will
be done in the first phase and then exit. The shell condition will not
be considered. So it will never report that the config.gypi is missing.

I've updated the recipe to use the echo command and an exit status. The
downside of this is that the error message is not as nice.

Current error message:
Makefile:81: *** Stale config.gypi, please re-run ./configure. Stop.

"New error message":
$ make config.gypi
Stale config.gypi, please re-run ./configure
make: *** [config.gypi] Error 1

To verify the stale config.gypi:
$ touch configure
$ make

To verfify that config.gypi is missing:
$ rm config.gypi
$ make

build: fix config.gypi target
The config.gypi target has a recipe that uses the control function error
to report if the config.gypi file is missing or if it is stale (the
configure file was updated which is a prerequisite of this rule).

GNU make has two phases, immediate and deferred. During the first phase
 it will expand any variables or functions as the makefile is parsed.
The recipe in this case is a shell if statement, which is a deferred
construct. But the control function $(error) is an immediate construct
which will cause the makefile processing to stop during the first phase
of the Make process.

If I understand this correctly the only possible outcome of this rule is
the "Stale config.gypi, please re-run ./configure"  message which will
be done in the first phase and then exit. The shell condition will not
be considered. So it will never report that the config.gypi is missing.

I've updated the recipe to use the echo command and an exit status. The
downside of this is that the error message is not as nice.

Current error message:
Makefile:81: *** Stale config.gypi, please re-run ./configure.  Stop.

"New error message":
$ make config.gypi
Stale config.gypi, please re-run ./configure
make: *** [config.gypi] Error 1

To verify the stale config.gypi:
$ touch configure
$ make

To verfify that config.gypi is missing:
$ rm config.gypi
$ make
@danbev

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Oct 12, 2016

Member

You could simply change the message to "Missing or stale config.gypi, please run configure". :-)

Member

bnoordhuis commented Oct 12, 2016

You could simply change the message to "Missing or stale config.gypi, please run configure". :-)

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Oct 12, 2016

Member

You could simply change the message to "Missing or stale config.gypi, please run configure". :-)

I'd like that :) Would that be acceptable?

Member

danbev commented Oct 12, 2016

You could simply change the message to "Missing or stale config.gypi, please run configure". :-)

I'd like that :) Would that be acceptable?

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Oct 12, 2016

Member

It's acceptable to me - but I may be biased. :-)

Member

bnoordhuis commented Oct 12, 2016

It's acceptable to me - but I may be biased. :-)

@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Oct 12, 2016

Member

@bnoordhuis :) I'm adding that as an option and let other decide what they prefer. Thanks!

Member

danbev commented Oct 12, 2016

@bnoordhuis :) I'm adding that as an option and let other decide what they prefer. Thanks!

@bnoordhuis

LGTM with a suggestion.

Show outdated Hide outdated Makefile Outdated

danbev added a commit to danbev/node that referenced this pull request Oct 14, 2016

build: fix config.gypi target
The config.gypi target has a recipe that uses the control function error
to report if the config.gypi file is missing or if it is stale (the
configure file was updated which is a prerequisite of this rule).

GNU make has two phases, immediate and deferred. During the first phase
 it will expand any variables or functions as the makefile is parsed.
The recipe in this case is a shell if statement, which is a deferred
construct. But the control function $(error) is an immediate construct
which will cause the makefile processing to stop during the first phase
of the Make process.

If I understand this correctly the only possible outcome of this rule is
the "Stale config.gypi, please re-run ./configure"  message which will
be done in the first phase and then exit. The shell condition will not
be considered. So it will never report that the config.gypi is missing.

bnoordhuis suggested that we simply change this into a single error
message:
"Missing or stale config.gypi, please run configure"

PR-URL: nodejs#9053
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
@danbev

This comment has been minimized.

Show comment
Hide comment
@danbev

danbev Oct 14, 2016

Member

Landed in: 0ed6338

Member

danbev commented Oct 14, 2016

Landed in: 0ed6338

@danbev danbev closed this Oct 14, 2016

@danbev danbev deleted the danbev:makefile-config.gypi-fix branch Oct 14, 2016

jasnell added a commit that referenced this pull request Oct 14, 2016

build: fix config.gypi target
The config.gypi target has a recipe that uses the control function error
to report if the config.gypi file is missing or if it is stale (the
configure file was updated which is a prerequisite of this rule).

GNU make has two phases, immediate and deferred. During the first phase
 it will expand any variables or functions as the makefile is parsed.
The recipe in this case is a shell if statement, which is a deferred
construct. But the control function $(error) is an immediate construct
which will cause the makefile processing to stop during the first phase
of the Make process.

If I understand this correctly the only possible outcome of this rule is
the "Stale config.gypi, please re-run ./configure"  message which will
be done in the first phase and then exit. The shell condition will not
be considered. So it will never report that the config.gypi is missing.

bnoordhuis suggested that we simply change this into a single error
message:
"Missing or stale config.gypi, please run configure"

PR-URL: #9053
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>

MylesBorins added a commit that referenced this pull request Nov 11, 2016

build: fix config.gypi target
The config.gypi target has a recipe that uses the control function error
to report if the config.gypi file is missing or if it is stale (the
configure file was updated which is a prerequisite of this rule).

GNU make has two phases, immediate and deferred. During the first phase
 it will expand any variables or functions as the makefile is parsed.
The recipe in this case is a shell if statement, which is a deferred
construct. But the control function $(error) is an immediate construct
which will cause the makefile processing to stop during the first phase
of the Make process.

If I understand this correctly the only possible outcome of this rule is
the "Stale config.gypi, please re-run ./configure"  message which will
be done in the first phase and then exit. The shell condition will not
be considered. So it will never report that the config.gypi is missing.

bnoordhuis suggested that we simply change this into a single error
message:
"Missing or stale config.gypi, please run configure"

PR-URL: #9053
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>

MylesBorins added a commit that referenced this pull request Nov 11, 2016

build: fix config.gypi target
The config.gypi target has a recipe that uses the control function error
to report if the config.gypi file is missing or if it is stale (the
configure file was updated which is a prerequisite of this rule).

GNU make has two phases, immediate and deferred. During the first phase
 it will expand any variables or functions as the makefile is parsed.
The recipe in this case is a shell if statement, which is a deferred
construct. But the control function $(error) is an immediate construct
which will cause the makefile processing to stop during the first phase
of the Make process.

If I understand this correctly the only possible outcome of this rule is
the "Stale config.gypi, please re-run ./configure"  message which will
be done in the first phase and then exit. The shell condition will not
be considered. So it will never report that the config.gypi is missing.

bnoordhuis suggested that we simply change this into a single error
message:
"Missing or stale config.gypi, please run configure"

PR-URL: #9053
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>

This was referenced Nov 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment