0

I am creating a cmake package config file (a Foo-config.cmake) for a pre-existing .dll not created by cmake.

The annoying thing is that the .dll depends on some data files.

When a user consumes my package in his own cmake project, I want the INSTALL target to install both the .dll and data files to his specified install location. I don't want him to have to write extra install() rules to do that.

  1. Is it good practice to write the install() rules directly in my Foo-config.cmake? Or is there a better way to do this, maybe with set_target_properties()? I just couldn't find the appropriate property for associating arbitrary file dependencies to a target.
  2. In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake, or is there something in cmake that can automatically generate it for me to achieve the same thing?

FWIW the .dll is an internal legacy library and is normally built by Visual Studio and uploaded in a .zip file to our internal artifactory. I want us to migrate away from manually pulling down .zip files from artifactory and manually integrating the files into Visual Studio projects.

Kevin
  • 673
  • 7
  • 21
  • Why would a user of your package want to install your package? The user wants to use your package, and install his program. If the user would want to install Foo, he would compile and install Foo. If the user wants to use Foo, he will want to use Foo, not install it. – KamilCuk Mar 15 '22 at 22:55
  • The user wants to install the .dll because their program depends on it to run. – Kevin Mar 15 '22 at 22:57
  • @KamilCuk I've added some additional context. This is for legacy internal libraries, with the larger goal of migrating away from manually futzing with msbuild projects. – Kevin Mar 15 '22 at 23:07
  • This is still confusing why would you want to install it as part of your application. In windos, you first install VC++ redistributable, which is a collection of .dll, then you insatll a program that uses VC++. Separately. If user would have two programs with same set of .dll installed to same location, they would overwrite each other, leaving system in inconsistent state. – KamilCuk Mar 16 '22 at 07:41
  • Is it that confusing? Let's say I want to create a docker container with all the dependencies needed for an application. Certain dependencies are dlls created by projects that know nothing about cmake or have no installer or aren't available on any package manager. I want to collect all dependencies for the application at once. Is that so strange? What about cmake's $? Maybe that can be leveraged. – Kevin Mar 16 '22 at 08:45

2 Answers2

0

I've since found that there are a couple different ways to do this:

Kevin
  • 673
  • 7
  • 21
-1

Is it good practice to write the install() rules directly in my Foo-config.cmake?

No.

From 480 *-config.cmake and *Config.cmake files on my system none calls install().

Or is there a better way to do this, maybe with set_target_properties()?

No.

In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake

No. This is unrelated to if you create a .dll or not. If .dll exists, there is no need to create Foo-config.cmake anyway. It is your choice that you want to (or make users to) use find_package.

is there something in cmake that can automatically generate it for me

No.

If you don't intent to support find_package features - VERSION OPTIONAL_COMPONENTS PATHS HINTS CONFIGS etc. - then just go with include(). find_package is just include() with some extra options.

If you want to have install() in your find_package, then just protect it with a variable, like if (FOO_DO_INSTALL) install(....) endif().

KamilCuk
  • 96,430
  • 6
  • 33
  • 74