Several issues with custom generated vcxproj

[jairbubbles]

I'm using that option:

Which appears as /wd"4100" /wd"4127" /wd"4201" /wd"4512" /wd"4592" /wd"4714" in the command line.

When using msfastbuild I get cl : Command line error D8021 : invalid numeric argument '/wd4714

Is there a way to add -showcmds to the fastbuild command line ?

(MS doc on this compiler flag: https://msdn.microsoft.com/en-us/library/thxezb7y.aspx)

[liamkf]

Hi! Sorry for the delay in responding, I was away on vacation, thanks for posting the issue! :)

It's planned to add a little options window to the vsix to make it easier to pass things through to FASTBuild, but nothing yet I'm afraid!

If you're building from the command line you can add -showcmds to the -a option, like so: msfastbuild -p ./bees.vcxproj -c Debug -f Win32 -a"-dist -showcmds"

The error is a bit of a mystery, as most of my projects use that option as well:

Disable Specific warnings 4514;4820;4710;4100;4244;4512

I do notice that in my bff file, the arguments are not escaped (despite what the 'command line' option in VS shows), and having /wd4714 as a parameter to CL seems pretty normal when building through both msbuild and msfastbuild.

So I am suspecting some sort of Visual Studio/MSBuild/Environment issue I'm not handling correctly, if it's a project or a bff file (which is generated in the same folder as the vcxproj file) which I can have a look at I'd be happy to try and help track down what's wrong. If not, any more information about OS/Compiler/Toolchain that you have could be useful!

Cheers, Liam

[jairbubbles]

Sure I'll send you the .bff tomorrow as I'm no longer at work !

[jairbubbles]

Here you go: Core.vcxproj_Release_x64.zip

There is indeed an issue for the last one: /wd4100 /wd4127 /wd4201 /wd4512 /wd4592 /wd"4714

In the vcxproj it looks like that:

<DisableSpecificWarnings>4100;4127;4201;4512;4592;4714
</DisableSpecificWarnings>

Maybe the carriage return ? (Our vcxproj is generated)

[liamkf]

Yup, putting a carriage return into one of my vcxproj gives me the same issue! Trimming the evaluated string seems fairly safe and passes all the tests so I've put that in. There's a new version available here: https://github.com/liamkf/msfastbuild/releases/tag/v0.11 please let me know if it fixes your issue! :)

[jairbubbles]

It seems you need to increase some internal version number.

Also, why don't you integrate fbuild.exe in your package ?

[jairbubbles]

I now have an issue with precompiled headers:

D:\Voyager\tools\NativeFramework\libs\Core\Registry\Registry.cpp(1): error C2858: command-line option 'program database name (/FdD:\Voyager\tools\NativeFramework\libs\Core\vc140.pdb)' inconsistent with precompiled header, which used '/FdD:\Voyager\tmp\vc_14.0\vs2015\nativeframework\libs\core\win64\release\core_compiler.pdb'
D:\Voyager\tools\NativeFramework\libs\Core\Registry\Registry.cpp(1): error C2859: D:\Voyager\tools\NativeFramework\libs\Core\vc140.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header.

It seems you're not compiling the pch.

[liamkf]

Sorry about that, I'll try to make sure to increment the version number appropriately. Looks like you managed to uninstall/reinstall it though. :)

I'm not opposed to integrating the fbuild exe into the package, but we're still changing fbuild on our side fairly often (and using a variety of versions) so it's more annoying than it's worth for now I think.

But yes, looks like your generated vcxproj has the precompiled header ClCompile node in a different place than I was expecting. There was no good reason for it being so restrictive though, so I've put up a new version that seems to generate a bff which has a reasonable looking pch setup. Hopefully it solves the issue for you!

[jairbubbles]

Thx ! I guess our badly generated projects will help you make it more robust ^^

So I switched to 0.12 and I have some files which get compiled !

But sadly it fails on another project. This is a very unusual project as it's a C++ project that contains a .cs file which can be compiled as C++ too. I guess you didn't handle that case by default ;-)

Building SharedConstants
D:\Voyager\projects\SharedConstants.vcxproj_Release_x64.bff(43,1): FASTBuild Error #1006 - Library() - Nothing defined to be built.
Library('output')
^
\--here
4/22 built.

Here are the bff and vcxproj for this project: SharedConstants.vcxproj_Release_x64.zip

[liamkf]

Haha yeah these are good tests! :)

I certainly haven't tried a project with a .cs file compiled as C++! From the bff it seems as though it skipped the ClCompile files completely which is unexpected!

It looks like the .zip is missing the vcxproj (it has the .user and .filters), can I get it to have a look?

[jairbubbles]

Oups I failed my zip. SharedConstants.vcxproj_Release_x64.zip

[liamkf]

Hmm, that is certainly a weird vcxproj! :D

I can't see that it actually builds anything! There's no ClCompile node, only ClInclude nodes, which as far as I can tell msbuild/VS ignore. I modified the vcxproj to refer to my own MetaDataCache.cs file, and building through VS or msbuild doesn't give any errors but also doesn't produce anything. Changing it from a header to a C/C++ file so that it becomes a ClCompile node seems to work as expected. I suppose I could handle the case where nothing is actually being built with a bit more grace.

Are you seeing it actually produce something? If so, can I see the msbuild log? I built it locally with: $>msbuild SharedConstants.vcxproj /p:Configuration=Debug;Platform=x64 /v:d > buildlog.txt, or alternately the output from VS with the MSBuild verbosity set to normal?

buildlog.txt

[jairbubbles]

Yeah you're completely right, this projet is just for sharing constants and in C++ it's only a .h. The project is only there for edition purpose. (and the pch seems pretty useless) IMHO you should not generate a .bff at all when the project has now interesting files at all.

[liamkf]

Ahh ok!

I don't actually mind its current behaviour, as it would allow people to have a bff file from an empty project with the current settings of the project they could add to as they see fit, but I suppose it's reasonable to emulate msbuild here and not have it give an error at least, so that's what I did for v0.13. :)

[jairbubbles]

With version 0.13 I can go to link but sadly it fails.

11>DLL: D:\Voyager\bin\tools\curlhttp_r.dll
11>LINK : fatal error LNK1181: cannot open input file 'bin/win64/release/core.lib'

11>Failed to build DLL (error 1181) 'D:\Voyager\bin\tools\curlhttp_r.dll'

It seems it doesn't find the lib which seems to be at the good place D:\Voyager\tools\NativeFramework\libs\Core\bin\win64\release\core.lib

CurlHttp.vcxproj_Release_x64.zip

FastBuildMonitor resets its view for each project is it intended ?

[liamkf]

Hmm yeah that's using the slightly rickety dependencies evaluation. I can't fully test what I think might fix it, which is getting the full path for the dependency inputs, so it's a bit of a blind fix. If it doesn't work if I could get the sln and all the vcxproj files (in the right folder structure) I'll try to see what else might work... :)

[jairbubbles]

Sadly it didn't fix the issues. Here is the project structure: test.zip

[liamkf]

Hmm, when I ran it, it replaced the relative path with a full path as I expected (and which I hope will work!), so I'm suspecting I may have uploaded the wrong release (or the old version of msfastbuild was used!). Want to give it a try with the new version I just posted? :) CurlHttp.vcxproj_Release_x64.bff.txt

[jairbubbles]

That's indeed possible as version was 1.3 in the extension manager. I'll check on monday.

[jairbubbles]

After installing the new version and cleaning the solution I still got an error but it's slightly different: 10>LINK : fatal error LNK1181: cannot open input file 'D:/Voyager/tools/NativeFramework/apps/MetaDataWalker/bin/win64/release/core.lib'

But the lib is supposed to be here: D:\Voyager\tools\NativeFramework\libs\Core*\bin\win64\release

So I guess you're not resolving with the good project root.

[liamkf]

I'm feeling lucky with the latest release... ;)

I'm not 100% confident, as the dll projects going four directories up seems like potentially cause problems, but the paths do seem reasonable. Please give a try and let me know how it goes!

[jairbubbles]

Well, we're almost there ! It's now failing during post build: Failed to spawn process for 'D:\Voyager\tools\NativeFramework\apps\FBXExcavator\postbuild.bat.txt'

[liamkf]

Ah yeah, I can see my build events are set up in a way that won't work for solutions. I'll give them a pass and use unique names in the project folders tonight. :)

[liamkf]

Ok build events should now be better about naming their batch files and placing them in their respective vcxproj folder! Postbuild is getting close to the end I hope! :D

[jairbubbles]

I tested quickly but I had the same error. I wanted to check the version but I couldn't open the extension manager as an error occured. Not sure I have the new version so maybe it's fixed maybe not.

[jairbubbles]

I confirm that I still have the issue:

6> Run: D:\Voyager\tools\NativeFramework\apps\FBXExcavator\postbuild.bat.txt
6> Failed to spawn process for 'D:\Voyager\tools\NativeFramework\apps\FBXExcavator\postbuild.bat.txt'
FBuild: Error: BUILD FAILED: all
Time: 1.212s
16/22 built.

[liamkf]

Hmm I think you might need to clean your .bff files, the new postbuild .bat file should look like FBXExcavator_postbuild.bat. Mine contains: call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 8.1

..\..\..\..\bin\fbxexcavator.exe -gtest --gtest_filter=-*slowtest* --gtest_output="xml:..\..\..\..\bin\FBXExcavator.test_detail.xml"

Which seems like it could work... what does running the .bat file on its own give you?

[jairbubbles]

I'll check that. It would be great to have a clean Fastbuild solution.

[jairbubbles]

It indeed worked. Now it's: LINK : fatal error LNK1181: cannot open input file 'D:/Voyager/projects/output/win64/release/sharedconstants.lib'

There is no cpp in that lib so no .lib are generated.

[liamkf]

Hmm, why is there a reference to the sharedconstants project if it has no output? And why does it have ReferenceOutputAssembly set to true? I mean I can skip adding the dependencies but it seems like an unusual setup to support... :)

[jairbubbles]

I would say the main reason is that the projects are generated and the SharedConstants project has no special property set.

The thing is that we use incremental linking and we link directly to .obj files from library (Use Library Dependency Inputs) . There si no .cpp in that library so we have no .obj in the linker command line. It fails if we disable that option on SharedContants: Severity Code Description Project File Line Suppression State Error LNK1181 cannot open input file 'D:\Voyager\projects\output\win64\release\sharedconstants.lib' MetaDataWalker D:\Voyager\tools\NativeFramework\apps\MetaDataWalker\LINK 1

Incremental linking is not supported with fastbuild ?

[liamkf]

Ah yeah I guess that makes sense! Fastbuild does support linking the objects rather the final libs with the LinkerLinkObjects field on the Exec node to help out /INCREMENTAL.

msfastbuild, despite passing the /INCREMENTAL along... with the way things are currently laid out won't work, as it requires the inputs from a separate bff file. What could work with the current setup is to guess the output of the ObjectList step and using those as the inputs for dependencies.

I'm not sure if I'll be doing that in the near future though, as I've been thinking it's probably a better solution to try and generate one .bff for the whole solution, which could also allow better parallelism of the builds and avoid some of these issues as well.

I'll add a note in the readme about "Use Library Dependency Inputs" for project references not being supported for now.

[jairbubbles]

Seems good to me. I was wondering also if the generation of the .bff could be an optional feature in msfastbuild and that this plugin would also be used with custom generated .bff solution.

[liamkf]

Just to note, places I've been where fastbuild bff's are all set up tended to just use the NMake custom build from visual studio so that the Build/Cancel all worked as expected from within VS. Might be something for you to try too!

[jairbubbles]

Yes that's the way we do too.

I think it's a too simple Visual Studio integration though. You miss for instance the ability to compile only one file for testing reason (using bff config).

I've read a comment where @ffulin said he would be nice to have a plugin to smooth things up a little bit in Visual Studio. We could imagine MSFastBuild could provide those feature for projet who already have a .bff generated + the bff autogeneration feature.

[ffulin]

@jairbubbles You're right: The FASTBuild generated projects use makefile projects which are pretty limited in terms of getting them to work exactly the way one might like. Some things, like individual file compilation, have additional complexities though. For example FASTBuild might not necessarily know the .obj file to target for a given cpp file until it's done at least one build before, and even then it's complicated further by things like Unity or custom build steps you might have configured.

Having said all that, I think better integration into VS is still possiblewould be nice. Since some nice people made a VS plugin for visualizing distribution/scheduling :), and I'm hoping we'll end up with that as a first-class citizen in the FASTBuild distribution, that might allow some of these issues to be made better by the same plugin hooking into various build/menu actions.

Perhaps in conjunction with that, I believe it's possible to make custom project types for VS, so perhaps a .fastbuildproj might be a solution to some of these problems as well.