[SERVER-46748] The new native Ninja support doesn't register newly added files Created: 10/Mar/20  Updated: 24/Apr/20  Resolved: 24/Apr/20

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Andrew Morrow (Inactive)
Resolution: Duplicate Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-46519 Regenerating ninja does not require t... Closed
Operating System: ALL
Sprint: Dev Platform 2020-04-20, Dev Platform 2020-05-04
Participants:

 Description   

The new native Ninja support doesn't register newly added files. For example, the commands_in_multi_doc_txn_params.idl file was added as of this commit. When I synced, my ninja build is now broken:

[2108/3893] Compiling build\ninja\mongo\db\commands.obj
FAILED: build/ninja/mongo/db/commands.obj
cl @build\ninja\mongo\db\commands.obj.rsp
src\mongo\db\commands.cpp(52,10): fatal error C1083: Cannot open include file: 'mongo/db/commands_in_multi_doc_txn_params_gen.h': No such file or directory
#include "mongo/db/commands_in_multi_doc_txn_params_gen.h"
         ^
[2141/3893] Compiling build\ninja\mongo\db\concurrency\lock_state.obj
ninja: build stopped: subcommand failed.



 Comments   
Comment by Andrew Morrow (Inactive) [ 24/Apr/20 ]

I believe that this has the same root cause as the broken regeneration setup identified in SERVER-46519. Closing as a duplicate.

Comment by Andrew Morrow (Inactive) [ 24/Apr/20 ]

kaloian.manassiev - I'm almost certain this is a dup of SERVER-46519. I pulled in ninja.next from my work there, and the above reproduction correctly compiles the file after regenerating.

Comment by Andrew Morrow (Inactive) [ 24/Apr/20 ]

kaloian.manassiev - I have an interesting further observation. If you run the above reproduction, and you run ninja a second time, it builds the file correctly. This suggests that a new, and correct, build.ninja was regenerated, but ninja didn't subsequently reload it as part of that execution. Re-running ninja then reloads the file, and you get a correct build. I'll need to dig in a bit more to understand why that might happen.

Comment by Andrew Morrow (Inactive) [ 23/Apr/20 ]

I just tried this out with the following sequence of commands in a clean tree on Linux:

  • git checkout a3915ffe09112029bd195959345f2dcdb4b71ab5~1
  • buildscripts/scons.py --ssl --variables-files= --variables-files=etc/scons/mongodbtoolchain_stable_gcc.vars --detect-odr-violations --dbg=on --opt=off VARIANT_DIR=ninja --ninja build.ninja ICECC=icecc MONGO_VERSION=4.4.0 MONGO_GIT_HASH=unknown
  • ninja build/ninja/mongo/db/commands.o
  • git checkout a3915ffe09112029bd195959345f2dcdb4b71ab5
  • ninja build/ninja/mongo/db/commands.o

I observed that the second Ninja invocation did regenerate build.ninja as expected:

$ git checkout a3915ffe09112029bd195959345f2dcdb4b71ab5
Previous HEAD position was c646b5413e SERVER-46369 Run mixed_version_replica_sets.js in required builder
HEAD is now at a3915ffe09 SERVER-46119: Added runtime server parameter to disable collection and index creation in multi document transactions.
 
$ ninja build/ninja/mongo/db/commands.o
[0/197] Regenerating /home/andrew/Documents/10gen/dev/src/mongodb/build.ninja

So, that part appears to be working as expected, however, compilation of commands.o failed:

[197/197] Compiling build/ninja/mongo/db/commands.o
FAILED: build/ninja/mongo/db/commands.o
PATH=/opt/mongodbtoolchain/v3/bin:/usr/local/bin:/opt/bin:/bin:/usr/bin /opt/mongodbtoolchain/v3/bin/g++ @build/ninja/mongo/db/commands.o.rsp
src/mongo/db/commands.cpp:52:10: fatal error: mongo/db/commands_in_multi_doc_txn_params_gen.h: No such file or directory
 #include "mongo/db/commands_in_multi_doc_txn_params_gen.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

The behavior is the same when using --ninja=next.

Comment by Kaloian Manassiev [ 10/Mar/20 ]

Yes, if I re-run the SCons command it does help. I would really prefer if ninja did this automatically though, so I don't have to save the SCons invocation somewhere.

Comment by Brooke Miller [ 10/Mar/20 ]

kaloian.manassiev, does re-generating the Ninja file help? 

Generated at Thu Feb 08 05:12:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.