How to make CMake set dependencies for a static library project? - cmake

I'm using Windows 10 Pro, Visual Studio 2022 and cmake version 3.26.0-rc3. In my Visual Studio solution I have a static library project, let's call it MyLib, which uses features from libxml2 i.e. it needs to link against libxml2.lib. Also in my solution there is an executable project, let's call it MyExe, which links against MyLib and also has libxml2.lib listed as a dependency in its project settings.
The problem is that in the CMakeLists.txt file of MyLib, target_link_directories and target_link_libraries do not seem to have any impact on the MyLib project settings, particularly Additional Library Directories and Additional Dependencies, respectively. For MyExe, those commands work as expected. If I fix the linker options for MyLib project settings manually in Visual Studio IDE, everything builds fine, but I don't think I should need to manually alter project settings initially created by CMake. So is there something I'm missing here - like that dependencies for a static library project need to be set in a different way in CMake - or is this a bug in CMake or Visual Studio? Are there any alternative ways to achieve the desired behavior and get the build to work?
In trying to find solutions for this I came across this very old post, but if I understood correctly it suggested adding an extra library project which sounds like a huge overkill for a simple thing like this which could be worked around by setting the project settings manually in Visual Studio IDE, so it's not an acceptable solution for me.

Related

Visual Studio 2019: CMake Generation Seems to be Stuck, CMakeLists.txt is still parsing

I'm trying to build an existing CMake project with VS 2019 Professional, and when I open the folder through VS, after a few seconds it says in the Output window that the CMake generation finished. However, when I switch to CMake Targets view in the Solution Explorer, it says that the CMakeLists.txt is still parsing..., and in the Project menu Generate Cache is greyed out but Cancel CMake Cache Generation can be selected (which doesn't seem to do anything" and also Delete Cache is greyed out. This makes me think that either VS doesn't think the CMake generation is done, or it's actually stuck somewhere.
Because of that I can't Build (no option under Build) and I can't Select a Startup Item/Target. I've searched and seen this issue a couple of times but there wasn't any answers/solutions.
Thanks!
Well, seems like updating my VS2019 solved that issue.

VStudio always compiles all the TargetFrameworks for referenced multi-target projects, whatever head is specified for a build in Uno-platform solution

I'm working on a cross-platform application using the Uno Platform.
The app consists of 5 standard head projects for my App and a dozen of referenced cross-platform libraries projects (Uno-platform cross-platform library projects, MSBuild.Sdk.Extras, VStudio 2019).
Referenced project libraries have multi-target frameworks specified like: netstandard2.0;xamarinios10;xamarinmac20;MonoAndroid90;monoandroid10.0.
Solution structure looks like this:
- SolutionApp
- App.Droid
- App.iOS
- App.macOS
- App.UWP
- App.Wasm
- App.Shared
- MultiTargetLibrary1
...
- MultiTargetLibraryN
The problem is that each time I rebuild any of the head app projects, VStudio rebuilds referenced projects for all the target frameworks available.
How to avoid a compilation of unnecessary target platforms?
How can a referenced project get which head project has triggered a build?
Is there any possibility to pass which exact target framework is needed in referenced project building from VStudio?
Example: I choose to rebuild App.iOS and it triggered a rebuild of referenced projects. I want projects with only 'xamarinios10' TargetFramework to be built.
If there are only a few target frameworks or projects compilation isn't slow, but with an increasing amount of referenced projects time extremely grows.
As I've got from msbuild reference: VStudio calls msbuild for each project on solution separately, so msbuild doesn't know which head project has triggered the build of the referenced project and which target platform is required.
This is a known Visual Studio 2019 issue, where all targets are built regardless of the actual head project being compiled.
In the meantime, you can manually exclude some target frameworks when building the application, and use the solution filter feature of Visual Studio so that nuget does not complain about invalid project references. That way, you can make 4 filters, with each excluding the projects that are not used for the platform you're currently working on.

Wrong package.appxmanifest picked by msbuild when packaging in command line

I have a C# solution with VS 2017, containing an app project, a desktop extension project, and a packaging project. As I mentioned in the answer of this question, I finally get msbuild to create a single bundle with both x86 and x64 for me. However, after I tried to install from that bundle, I found that msbuild actually picked up the wrong package.appxmanifest because they have different version numbers.
So... I have two package.appxmanifest, one in packaging project, and one in my main app project. When I build from the wizard in VS 2017, the one in packaging project will be used, which is correct. When I use msbuild to build with just one platform, it will pick the right one as well, like this:
msbuild .\MyApp.sln /p:Configuration=Release /p:Platform=x86
Only when I use msbuild to build two platforms together, it will use the one in my main app project:
msbuild .\MyApp.sln /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64" /p:UapAppxPackageBuildMode=StoreUpload
I also tried to build the packaging project instead of the solution, but because our desktop extension project is only x86, I will get errors about configurations when building x64.
Questions:
Does anyone know why this is happening?
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the platform, which platform is used to build?
Should I add <AppxBundle>Always</AppxBundle> or <AppxBundle>Never</AppxBundle> to the packaging project?
Does anyone know why this is happening?
That because you have two Package.appxmanifest files with same ID in the solution. When you create the App Bundle with .sln, MSBuild/Visual Studio could not to know clearly which Package.appxmanifest should be use.
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the
platform, which platform is used to build?
Not sure the reason why you can not specify the platform. To resolve this issue, you can try yo build the project file .csproj instead of the solution file. For example, when you build the app project, you can use the command line:
msbuild .\MyApp.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64"
And then build the packaging project:
msbuild .\YouPackaging.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86"
Should I add Always or
Never to the packaging project?
If you build the project, no need to add those two properties to the project file, those two properties are used to the solution level and you have a project that you do not want to add to the bundle:
because at the solution level, it’s not clear which app should appear
in the bundle. To resolve this issue, open each project file and add
the following properties at the end of the first
element
Hope this helps.

How to add libraries to dll project in VS2013?

I've got a code in C++ built with some libraries like vtk, fltk, pcl and kinect SDK in Visual Studio 2010. My task is taking this project and integrate it into another C#.NET project with Visual Studio 2013.
I was told to do a new project for the dlls and copy the code I need there to make a wrap. My current problem is that I do not know how to add the references so my code can find the includes for the libraries and compile. I have tried to add the .h and .lib manually but does not work. May you give me any hint?
Thank you.
I'm not entirely clear what your question is, but try this:
Right click on your project in the solution explorer and go to Properties -> Configuration Properties -> Linker -> Input.
In the additional dependencies field, add your .lib file(s).
remember to #include the corresponding header files in your source file.

Statically link to the dll files

I have already built a project, and run it in VS2010.
But if I want to run the .exe on other computers which does not
install Visual Studio, it will need .dll files (such as msvcrt.dll and
msvcp60.dll in WINDOWS\SYSTEM32, and some other dlls in the
development package). I didn't use MFC in this project. How to static
link all these dlls into the .exe file in Visual C++ so that I don't
have to copy all the dlls to the other machines?
BTW: I don't want to make install package either
Thanks
Siba
You can set your project to statically link the CRT, by using the /MT flag for the runtime library. Or, you could keep the /MD setting, and install the vcredist package along with your executable (you can get it from here, and also from one of your VS2010 installation folders). To get an idea of each options pros and cons, read this.
Oh, and a similar question has been asked before...