[SERVER-46673] The new ninja generator does not build the 'vcxproj' target Created: 06/Mar/20  Updated: 28/Aug/23  Resolved: 28/Aug/23

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: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Server Development Platform
Operating System: ALL
Sprint: Dev Platform 2020-04-20, Dev Platform 2020-05-04
Participants:

 Description   

The vscproj SCons target is what produces a Visual Studio project and is very handy for people who develop on Windows, with VS. With the old ninja generator I could just run ninja vcxproj and get a VS project, but the new ninja generator doesn't seem to produce one:

E:\workspace\mongo>ninja vcxproj
ninja: error: unknown target 'vcxproj'
 
E:\workspace\mongo>ninja compiledb
[0/1] Building compile_commands.json

It should be on the same parity as compiledb.



 Comments   
Comment by Kaloian Manassiev [ 06/May/20 ]

OK, this sounds good to me. I have a workaround, so I am good.

Thanks for looking into it!

Comment by Andrew Morrow (Inactive) [ 06/May/20 ]

I see what is going on. With the old Ninja Module, the generated build.ninja reached out to SCons to build the compile_commands.json which it knew was a dependency of mongodb.vcxproj, and which it knew how to build as a command by running make_vcxproj.py. However, in the new Ninja Generator world, the production of compile_commands.json has been entirely delegated to Ninja. So there is no way in the SCons declarations to express that mongodb.vcxproj depends on this entity that only exists in the Ninja world. It isn't really clear how to address that. For now, since there is a workaround, I'm going to move this ticket into our general queue of build system improvements. I don't think it blocks rolling out hygienic builds to developers.

Comment by Kaloian Manassiev [ 06/May/20 ]

I am not sure what you mean "how it worked with the old ninja module"? Are you asking how it was implemented (because I don't know) or what was the command?

For the latter, I could (and I just checked that I still can) just run "ninja vcxproj" and I ended up with a mongod.vcxproj file:

D:\workspace\mongodb-4.2> buildscripts\scons.py -j 33 ^
  --ssl --win-version-min=ws08r2 --link-model=object --pch ^
  --dbg=on --opt=off ^
  CPPPATH="D:/workspace/libs/snmp/include D:/workspace/libs/sasl/include D:/workspace/libs/openssl/include" ^
  LIBPATH="D:/workspace/libs/snmp/lib D:/workspace/libs/sasl/lib D:/workspace/libs/openssl/lib" ^
  CPPDEFINES="_SILENCE_CXX17_ITERATOR_BASE_CLASS_DEPRECATION_WARNING" ^
  MONGO_GIT_HASH="unknown" MONGO_VERSION="0.0.0" VARIANT_DIR=ninja build.ninja
...
D:\workspace\mongodb-4.2>ninja vcxproj
[1/2] Checking for compiler upgrades
[0/2] SCONSGEN compile_commands.json
scons: running with args C:\Python37\python.exe D:\workspace\mongodb-4.2\buildscripts\scons.py -Q -j 33 --ssl --win-version-min=ws08r2 --link-model=object --pch --dbg=on --opt=off CPPPATH=D:/workspace/libs/snmp/include D:/workspace/libs/sasl/include D:/workspace/libs/openssl/include LIBPATH=D:/workspace/libs/snmp/lib D:/workspace/libs/sasl/lib D:/workspace/libs/openssl/lib CPPDEFINES=_SILENCE_CXX17_ITERATOR_BASE_CLASS_DEPRECATION_WARNING MONGO_GIT_HASH=unknown MONGO_VERSION=0.0.0 VARIANT_DIR=ninja compile_commands.json
...
Building compilation database compile_commands.json
[2/2] C:\Python37\python.exe buildscripts\make_vcxproj.py mongodb
...
D:\workspace\mongodb-4.2>dir
 Volume in drive D is HDD
 Volume Serial Number is 5A4D-1D1D
 
 Directory of D:\workspace\mongodb-4.2
 
05/06/2020  09:32 AM    <DIR>          .
05/06/2020  09:32 AM    <DIR>          ..
07/29/2019  12:21 PM             6,709 .clang-format
06/04/2019  07:51 AM                29 .eslintignore
06/04/2019  07:51 AM               795 .eslintrc.yml
06/04/2019  07:51 AM               308 .gdbinit
06/04/2019  07:51 AM                74 .gitattributes
04/04/2020  06:33 AM             2,052 .gitignore
05/06/2020  09:32 AM                16 .ninja_deps
05/06/2020  09:32 AM               520 .ninja_log
06/04/2019  07:51 AM               588 .pydocstyle
06/04/2019  07:51 AM             1,703 .pylintrc
06/04/2019  07:51 AM               193 .style.yapf
06/04/2019  07:51 AM            11,358 APACHE-2.0.txt
05/06/2020  09:31 AM    <DIR>          build
05/06/2020  09:31 AM        65,750,525 build.ninja
05/06/2020  09:31 AM            16,255 build.ninja.deps
05/06/2020  09:30 AM    <DIR>          buildscripts
05/06/2020  09:32 AM         5,880,030 compile_commands.json
...
05/06/2020  09:32 AM         1,125,940 mongodb.vcxproj
05/06/2020  09:32 AM         1,086,544 mongodb.vcxproj.filters
...

Thanks for the workaround - I actually was just running the vcxproj target with scons.py directly, so I am not blocked.

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

kaloian.manassiev - Could you clarify for me how this worked with the old ninja module? From what I can see, the make_vcxproj.py script requires the presence of a compile_commands.json file in order to run. In pure SCons, this is fine, because we can specify that compile_commands.json is an input to the command that will run make_vcxproj.py. But if that is true, then I would expect that with the old Ninja module, either:

1) Running ninja vcxproj in a clean repo where build.ninja was just generated would fail, because there would be no compile_commands.json available, OR
2) Running ninja vcxproj in a clean repo where build.ninja was just generated would immediately re-invoke SCons to produce compile_commands.json and then invoke the make_vcxproj.py script.

Could you please try it with the old module and let me know which happens? I think it is going to be difficult to make this work seamlessly. For most things, SCons level dependency edges get mapped into Ninja level dependency edges. But the compilation database is handled differently: since Ninja can generate it directly, the SCons level compiledb generation is disabled. In order to map the vcxproj target into Ninja, we would need some way to express, up at the SCons layer, that vcxproj should, when mapped down to Ninja, depend on the Ninja generators version of producing the compilation database. I'm not sure how possible that is.

For now, while we investigate this, please note that there is a simple workaround: generate compile_commands.json via any mechanism, and then just manually invoke buildscripts/make_vcxproj.y --version 14.2 mongod, rather than asking the build system to do it for you.

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