[CMake] Dealing with dll PATH on Windows

[David Cole]

If you want to write reg values with cmake, you can execute cmake as a
sub-process with -E command line args (for example, using
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} .... in your CMakeLists.txt file)

Use the write_regv -E sub-command:

cmake -E
CMake Error: cmake version 2.6-patch 0
Usage: cmake -E [command] [arguments ...]
Available commands:
  chdir dir cmd [args]...   - run command in a given directory
  copy file destination     - copy file to destination (either file or
directory)
  copy_if_different in-file out-file  - copy file if input has changed
  copy_directory source destination   - copy directory 'source' content to
directory 'destination'
  compare_files file1 file2 - check if file1 is same as file2
  echo [string]...          - displays arguments as text
  echo_append [string]...   - displays arguments as text but no new line
  environment               - display the current enviroment
  make_directory dir        - create a directory
  md5sum file1 [...]        - compute md5sum of files
  remove_directory dir      - remove a directory and its contents
  remove [-f] file1 file2 ... - remove the file(s), use -f to force it
  tar [cxt][vfz] file.tar file/dir1 file/dir2 ... - create a tar archive
  time command [args] ...   - run command and return elapsed time
  touch file                - touch a file.
  touch_nocreate file       - touch a file but do not create it.
  write_regv key value      - write registry value
  delete_regv key           - delete registry value
  comspec                   - on windows 9x use this for RunCommand




On Fri, May 23, 2008 at 12:07 PM, KSpam <keesling_spam at cox.net> wrote:

> Arjen,
>
> On Thursday 22 May 2008 23:35:33 Arjen Markus wrote:
> > Having CMake set the necessary registry entries would not help with
> > binary distributions of your product. I do not whether that is relevant
> > to you, but in general that would be a problem:
> > - Your clients may have the libraries installed in a different place
> > - They may have different versions
> > - They may lack the permissions to install libraries
>
> My concern is not for binary distributions.  For binary distributions, I
> create a NSIS installer that automatically sets PATH (we put all of our
> dlls
> in a single directory for distributions).
>
> I am trying to make PATH easier to deal with for developers.  Our project
> keeps all dependency third party libraries in a single external directory.
> Developers will sometimes work with different versions of a library.  For
> instance, some developers will build with QT-4.3.3, and others will build
> with QT-4.4.0.  This is easy to handle on the build side with CMake.  The
> problem I run into is that two different versions of QT require different
> dlls, and I have to ensure that the path is set properly to find the
> correct
> version of the QT dlls.  I know exactly what the PATH needs to be from my
> CMake configuration variables.  I simply want to be able to apply that
> knowledge to set PATH automatically for users.
>
> Using the add-in mentioned in my previous post would allow me to do this:
>
> http://workspacewhiz.com/OtherAddins.html#SolutionBuildEnvironment
> http://www.workspacewhiz.com/SolutionBuildEnvironmentReadme.html
>
> In order to use the add in, I would need to generate a simple
> (one-line) .slnenv file for each .sln file generated.  I was enquiring as
> to
> the best way to add generation support for creating the .slnenv files.  I
> am
> guessing that I would actually have to modify the Visual Studio generator.,
> but I am hoping for a less-intrusive solution.
>
> Another possible solution would be to write out environment variables to
> the
> registry from CMake; however, it seems that writing to the registry is not
> currently possible.
>
> Thanks,
> Justin
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20080523/980fdc61/attachment.htm>