Am 31. Oktober 2014 20:51:55 MEZ, schrieb Bill Somerville
b...@classdesign.com:
On 31/10/2014 19:42, Michael Jackson wrote:
Never said it was pretty, but here is the code I use for Qt4 based
projects. I think I had to revamp a lot of this for Qt5. I call it like
so:
The thing I could never figure out is how to set the PATH for the Visual Studio
Project/Solution. That is what I need. If I only had a single version of Qt on
my system it would be very straight forward. Just set the PATH environment
variable using the standard windows mechanism for doing that
I agree that if the FindQt4 would enumerate the DLLs that would be great and
simply get ride a bunch of this home-brew code that I have to write for each
library. Getting the Plugins would also be a great help also since I have to
grab a few of those. the FindQt5 module does this I think.
On 01/11/2014 14:02, Michael Jackson wrote:
Hi Michael,
I agree that if the FindQt4 would enumerate the DLLs that would be great and
simply get ride a bunch of this home-brew code that I have to write for each
library. Getting the Plugins would also be a great help also since I have to
grab a
Mike,
You can modify or override the PATH variable in Visual Studio by pulling up
the properties for the startup project and going to Configuration
Properties - Debugging, and add an entry for your preferred PATH under the
Environment setting. By default, this will merge your PATH with the PATH
On 01/11/2014 14:15, Cory Quammen wrote:
Mike,
You can modify or override the PATH variable in Visual Studio by
pulling up the properties for the startup project and going to
Configuration Properties - Debugging, and add an entry for your
preferred PATH under the Environment setting. By
I've solved the problem that way in the past.
What you do is copy the .user file and make the environment setup
driven by configure_file() in CMake. That way at CMake configure time
you can create a .user file for each .VCPROJ that has PATH setup to
point to third party BIN directories as needed.
I like this idea but it doesn't seem like it will work for targets
with multiple DLLs... for example boost. It has several DLLs. I don't
want to define 1 target for each DLL either. Sometimes that doesn't
make sense.
On Wed, Oct 29, 2014 at 10:45 AM, Hendrk Sattler
p...@hendrik-sattler.de wrote:
It sucks, but I do that with Qt's libraries. One target for each library. I
prefix the target with ZZ_ so that in IDEs like Visual Studio and Xcode those
targets fall to the bottom of the list. I also group them in folders if Visual
Studio will allow it. I use the copy if different argument to
If it were only a matter of style / visual annoyance, I wouldn't mind.
However it complicates dependency management when you have to specify
ZZ_QT_LIB1, ZZ_QT_LIB2, etc... instead of just QT when calling
target_link_libraries().
Unless you do it differently...
On Fri, Oct 31, 2014 at 2:28 PM,
Never said it was pretty, but here is the code I use for Qt4 based projects. I
think I had to revamp a lot of this for Qt5. I call it like so:
CMP_COPY_QT4_RUNTIME_LIBRARIES( QtCore;QtGui;QtNetwork)
#
#-- Copy all the Qt4
Am 31. Oktober 2014 20:11:23 MEZ, schrieb Robert Dailey
rcdailey.li...@gmail.com:
I like this idea but it doesn't seem like it will work for targets
with multiple DLLs... for example boost. It has several DLLs. I don't
want to define 1 target for each DLL either. Sometimes that doesn't
make
So much work to go to an intermediate location... you can't distribute from
there easily... it only makes development minorly simpler...
and if you're copying resources(data) to that location just to be able to
test from immediate output instead of a copy of the distribution..
install( files
On 31/10/2014 19:42, Michael Jackson wrote:
Never said it was pretty, but here is the code I use for Qt4 based projects. I
think I had to revamp a lot of this for Qt5. I call it like so:
CMP_COPY_QT4_RUNTIME_LIBRARIES( QtCore;QtGui;QtNetwork)
This seems an awful lot of messing around when
Am 31. Oktober 2014 20:28:00 MEZ, schrieb Michael Jackson
mike.jack...@bluequartz.net:
It sucks, but I do that with Qt's libraries. One target for each
library. I prefix the target with ZZ_ so that in IDEs like Visual
Studio and Xcode those targets fall to the bottom of the list. I also
group
PATH entries could
easily end up overflowing Windows' limit on the length of PATH.
--
Daniel
-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Somerville
Sent: Friday, October 31, 2014 12:52 PM
To: cmake@cmake.org
Subject: Re: [CMake] Copying DLLs to output
On 31/10/2014 20:46, Daniel Schepler wrote:
And what if there are more dependencies? For example, we have a project here
that uses Qt, Boost, OGRE, MYGUI, GDAL, Protobuf and EXPAT at least. And then
if some of those builds aren't self-contained, you could add in dependencies
like OpenSSL,
: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Somerville
Sent: Friday, October 31, 2014 2:12 PM
To: cmake@cmake.org
Subject: Re: [CMake] Copying DLLs to output directory
On 31/10/2014 20:46, Daniel Schepler wrote:
And what if there are more dependencies? For example, we have a project
On 31/10/2014 21:18, Daniel Schepler wrote:
In my online research, I was finding limits more like 1024 or 2048 characters
maximum. But if 32767 bytes is the real limit, and there are no compatibility
issues with certain programs for values longer than 1024 characters, that would
be great.
Am 2014-10-28 18:25, schrieb Robert Dailey:
I have a third party library like OpenSSL prebuilt for each platform
and in my own structure in version control. I have a CMake script that
creates an INTERFACE library target for it. I setup the include
directories and link targets. However, I don't
I have a third party library like OpenSSL prebuilt for each platform
and in my own structure in version control. I have a CMake script that
creates an INTERFACE library target for it. I setup the include
directories and link targets. However, I don't see a way to configure
DLLs in the interface
This actually used to be a very difficult problem to solve. However,
to debug in visual studio it's essential.
If I have DLLs located in third party directories OR from targets that
I depend on, those must all be copied to the directory of the
executable I'm debugging in order for those DLLs to
If you add install rules, you can get a runnable package... and kill having
to configure things to package in one step.
Install can just target 'output' or some relative directory to the build
directory, it doesn't have to be the final install target.
On Mon, Oct 27, 2014 at 6:55 PM, Robert
I use a copy rule for the DLLs during the build which finds the DLL and then
copies it to the Debug or Release directory. You are welcome to the macro that
we use for our project. If there is an easier way with Cmake 3.0.x I would love
to hear about it.
Thanks
Mike Jackson
On Oct 27, 2014,
how does that work with say openwatcom?
On Mon, Oct 27, 2014 at 7:51 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
I use a copy rule for the DLLs during the build which finds the DLL and
then copies it to the Debug or Release directory. You are welcome to the
macro that we use for
Well basically, if you are on windows cmake can find the .lib file but then I
wrote some code for each 3rd party library that attempts to find the .dll
files. Once those files are found I create the copy files targets for each DLL.
Mike Jackson
On Oct 27, 2014, at 11:17 PM, J Decker
Hi,
you can use generator expression in a post build rule to copy the dll file to
the same target dir as the target you link it with. The easiest way to do this
is to properly define all 3rd party libraries as imported targets that contains
both, the lib and the dll file.
Sadly, the FindQt4 on
27 matches
Mail list logo
