How to generate C++ source code via command line? #5890
Replies: 1 comment 4 replies
-
| I didn't actually change anything with my 1.7 scripts. The big thing that I did was to write a script to basically replicate the 1.7 layout.  The biggest special case was the interactive experiences metapackage.  The contents of these should end up in the  So the script essentailly had to extract the NuGet package, look for |
Beta Was this translation helpful? Give feedback.
-
| Thank you for replying, I appreciate it! I was afraid that hardcoding things such as the "metadata" name and relying on subfolders etc. isn't going to be reliable in the long term. Also I wasn't sure about "lib" folders and "-input" vs. "-ref" for cppwinrt.exe. Is your script published somewhere, by any chance? |
Beta Was this translation helpful? Give feedback.
-
| Unfortunately, I can't publish it. But to answer the question of -input vs. -ref, basically -input tells CppWinRT to generate headers for that metadata file, and -ref tells CppWinRT that the files exist but they won't be used for header generation. Basically, -ref is there for dependency resolution. To give example information from one of the projects, what my script does is generates response files and then uses those files to execute CppWinRT. CppWinRT is executed twice, the first generates the headers for Windows: Notice that all of these are specified using -in, CppWinRT accepts this as an abbreviation for -input. Next, I run CppWinRT with the references to the Windows App SDK. Notice that anything that I originally specified with -in is now specified with -ref, and the Windows App SDK references now all use -in. As far as hardcoding directories, that is always a problem. As 1.8 showed, the directory structure can change, so you really have to keep on top of things. We did have a fair amount of warning since the changes happened in 1.8-experimental 2. But in the end, when using a custom build system, we kind of have to fudge things at times. The directory layouts should stay pretty stable because it is easier for Visual Studio too. |
Beta Was this translation helpful? Give feedback.
-
| Ideally, I just wish I could do it with a single command or a set of simple commands, be it with a tool shipped with MSVC, with the SDK, or even some MS-maintained script I can clone. Doing it myself and being on top of things is suboptimal, and especially scary if there's some silent bad generation. In any case, perhaps my use case is niche so I guess I need to find a way. Your comments help, thanks. |
Beta Was this translation helpful? Give feedback.
-
| The problem generally is that no two build systems are really alike. This means that scripts that others write may be useless because there are assumptions or settings that do not apply to your build system. To make these scripts generally more useful, there is the option of adding options, but this can then make the scripts more problematic to use. To give a little example, the scripts that I use uses a couple of proprietry tools. The scripts then scans for the files that it needs and then generates 7 files, 5 response files for command line tools, and 2 data files for another tool. The scripts generates these files in the aux subdirectory, and the scripts references these files from the aux subdirectory. If you wanted to use these scripts, then you would have to adhere to the directory structure of my scripts, and the file names. What is the probability that you are using the same naming? What is the probability that any modifications would be trivial? Using scripts other people write would require just as much testing as any scripts that you write, so it isn't going to be as simple as dropping it in and using it. You would also be responsible for keeping an eye on updates to that script, testing them and properly integrating them with your build system. What's worse, the author could just abandon the script and you will then be left having to deal with that situation. A build system can require a lot of work to keep it working smoothly. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
For historical reasons, we have a CI pipeline that downloads the SDK nuget and generates the C++ headers. It uses cppwinrt.exe and some simple scripting. With the split of the nuget to several components, it's no longer so simple to generate it. Even if I resolve the dependencies from the nuspec file manually, I need to parse the targets, for example in
Microsoft.WindowsAppSDK.AI:to know which .winmd files are to be passed to cppwinrt.exe.
Visual Studio does all this automatically when building a project.
Is there a way to generate the headers without having to do all the target parsing etc. manually and without Visual Studio (or msbuild and an ugly throwaway project)?
Beta Was this translation helpful? Give feedback.
All reactions