On Thu, Oct 30, 2014 at 2:25 PM, Brad King brad.k...@kitware.com wrote:
On 10/30/2014 01:55 PM, Richard Shaw wrote:
I'm working on a big update to the FindFLTK module and I'm
testing it on all platforms I have access to.
One problem that took me quite a while to figure out was that
on
Does anybody ready to implement it or you want me to send the patches?
Ruslo
On 29-Oct-14 16:48, Brad King wrote:
On 10/28/2014 04:28 PM, Ruslan Baratov wrote:
What do you think about this:
Thanks for drafting the signature.
file(
LOCK path
[DIRECTORY] # if present locked file
On 10/31/2014 09:07 AM, Ruslan Baratov wrote:
Does anybody ready to implement it or you want me to send the patches?
Please work on the patches. You can use git format-patch to format
them and post here either inline or as attachments.
Thanks,
-Brad
--
Powered by www.kitware.com
Please
On 10/30/2014 07:19 PM, Eric Wing wrote:
Just curious, are the new WinRT changes the same exact changes from CMakeMS?
Yes. After prototyping the changes in CMakeMS they worked with us
to contribute the functionality upstream.
-Brad
--
Powered by www.kitware.com
Please keep messages
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15230
==
Reported By:Lekensteyn
Assigned To:
We actually have a couple if extra changes that are not fully ready to be
pushed upstream yet.
~Gilles
Sent from my Windows Phone
From: Brad Kingmailto:brad.k...@kitware.com
Sent: 10/31/2014 8:26
To: Eric Wingmailto:ewmail...@gmail.com
Cc: Robert
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15231
==
Reported By:Charles Karney
Assigned To:
Thanks Brad! Its working with my system curl!
Here is the curl version I am using.
curl 7.38.1-DEV (Linux) libcurl/7.38.1-DEV OpenSSL/1.0.1f zlib/1.2.8
libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s
rtsp scp sftp smtp smtps telnet tftp
On 10/31/2014 01:25 PM, Jameson Merkow wrote:
Thanks Brad! Its working with my system curl!
Great!
Shall I wait till you complete re-adding curl into the cmake build to submit?
If you don't mind, yes. I'd prefer not to make further modifications to
the current version of curl in CMake
On 10/29/2014 09:50 AM, Ben Boeckel wrote:
On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote:
Fedora is pushing to have higher resolution icons for the applications. There
already is CMakeSetup128.png, but these would need to get installed into the
proper /usr/share/icons/
I have only used MinGW-w64 for years and MinGW Makefiles works just fine. The
main difference between MinGW-w64 and the original MinGW is that it is far more
up to date.
Binary packages can be found here: http://mingw-w64.sourceforge.net/download.php
I generally recommend using the mingw-builds
On 2014-10-31 08:14- Mueller-Roemer, Johannes Sebastian wrote:
I have only used MinGW-w64 for years and MinGW Makefiles works just fine. The
main difference between MinGW-w64 and the original MinGW is that it is far more
up to date.
Binary packages can be found here:
mingw32-make, and yes it's included (I recently started using ninja as well,
but that isn't included, and has some limitations with cmake)
--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
On 10/30/2014 07:19 PM, Eric Wing wrote:
Just curious, are the new WinRT changes the same exact changes from CMakeMS?
Yes. After prototyping the changes in CMakeMS they worked with us
to contribute the functionality upstream.
-Brad
--
Powered by www.kitware.com
Please keep messages
We actually have a couple if extra changes that are not fully ready to be
pushed upstream yet.
~Gilles
Sent from my Windows Phone
From: Brad Kingmailto:brad.k...@kitware.com
Sent: 10/31/2014 8:26
To: Eric Wingmailto:ewmail...@gmail.com
Cc: Robert
Hello!
I have a C CMake project, and I would like to add the following feature:
1) define an interface for a second dynamic library
2) look in a specified folder at runtime, and try to load this library
3) if loading fails, then get notified of this fact, so that I can use
statically linked
Hello,
Yes, this can be done with ITK's object factory mechanism. I would study how
it's done with ITK's ImageIO plugin mechanism[1], then figure out how to adapt
the same framework for your interface.
Brad
[1] http://www.itk.org/Wiki/Plugin_IO_mechanisms
On Oct 31, 2014, at 2:20 PM,
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
Hi, we have several projects setup where the main target has a dependency on a
smaller target and the smaller target’s executable gets copied into the main
target’s OS X app bundle. We’ve been doing this with a combination of getting
the target’s LOCATION property and making that path a source
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, libjpeg, libpng, etc. It seems like all those
I was working on a find module, and ran into some rather unpredicted
behavior - it appears that including ENV ProgramFiles at the end the
list of PATHS makes the search fail! Remove that line, put it first, or
put it in quotes, and it works just fine. Does anyone have any clue why
this might
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,
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.
--
Daniel
-Original Message-
From:
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.
really nothing at all to do with cmake; a couple macros and you can support
cross-platform... a few less and you can init interfaces pretty easily
at the end of init or during early discovery of functions, if they fail you
can fillthe interface with static methods or return a different
On Fri, Oct 31, 2014 at 5:48 PM, J Decker d3c...@gmail.com wrote:
really nothing at all to do with cmake; a couple macros and you can
support cross-platform... a few less and you can init interfaces pretty
easily
at the end of init or during early discovery of functions, if they fail
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 752fe56cd3d850f12ed18cb35e1718639603edb8 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 7deb590ad4cc23fee416327d3e785ba1fc506957 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 9c8d08217cd578e1095254f16ccdaf1f44e25b33 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 1a6b2941020c96a653c51397df3800fc93f50568 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 188536844cdbffd7be52c2b1b8ff8a9846d20cab (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 14a983cce69610a1ed1b57e666d29fdbef4f7cd4 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via f2805bd01b011604f95f384ce1759c15503d32cc (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 163868b311158618184a98560ad8cffe3a1a9164 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 0b8db9ced19bf6ef3fa8a23625b47a7f9bdfdd4e (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 415cfd789dc86d9c7cbc5fbabd49e1f4e5799c02 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 81441f328b8f09784afdccebab2e134b1de16919 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, release has been updated
via aa0f6e83093486b0e7276aaddf5bf95f7c8419ce (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 311227b6d8629e4d6b65c8e57d706ae6fcb07ee0 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 8b16e62c7a10c246744327cde38b0b1d70eb8c48 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 13cbd0344b9f4a3ecf9e19c42f9125093ca9cc95 (commit)
via
20141031)
+set(CMake_VERSION_PATCH 20141101)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
49 matches
Mail list logo
