Am using BundleUtilities, in CPack-based Mac and Windows installers
for my Qt based project, exactly in the way described at following
Wiki page: http://www.cmake.org/Wiki/BundleUtilitiesExample.
Everything works fine, but there is slight problem with Windows
installer: namely, when plugins install
When I waited until after 11:54 am, and ran this just now, I got a
full build the first time, and then a "do nothing" incremental rebuild
the 2nd time.
So I guess this is a case of "works for me" -- there's something odd
about your machine or environment...? Has anybody else experienced
anything l
Hi all,
another one on mixed Fortan/C{++} executables here.
Suppose you have one C{++} source file, a Fortran one, and a C{++}
main. They all need to be compiled and linked into an executable.
There are different situations where CMake doesn't do what I expected:
(* All GCC, the linker is gfor
Hello Michael Wild,
I regret deciding to go with an Python parser for my application. I use
such a small subset of the API, I was hoping to be able to rerelease my app
everytime it changes.
Apparently Python 2.6 is frozen.
In the future, the Python people are hoping to stabilize the ABI in the
On Thu, Dec 30, 2010 at 09:42, Michael Wild wrote:
> On 12/30/2010 03:34 PM, Ian Monroe wrote:
>> On Thu, Dec 30, 2010 at 08:08, Michael Hertling wrote:
>>> On 12/30/2010 11:33 AM, Ian Monroe wrote:
To create my QyotoConfig.cmake I need to know the full path of a
library so that I can s
I think, the problem with FindFLTK is, that it has never been tested on
Windows. If you take a look at FindFLTK you will detect the following
lines:
# if FLTK was not built using CMake
# Find fluid executable.
FIND_PROGRAM(FLTK_FLUID_EXECUTABLE fluid ${FLTK_INCLUDE_DIR}/fluid)
#
On 12/30/2010 03:34 PM, Ian Monroe wrote:
> On Thu, Dec 30, 2010 at 08:08, Michael Hertling wrote:
>> On 12/30/2010 11:33 AM, Ian Monroe wrote:
>>> To create my QyotoConfig.cmake I need to know the full path of a
>>> library so that I can set a variable like QYOTO_LIBRARY.
>>>
>>> This is pretty s
On 12/30/2010 11:01 AM, Julia Jacobson wrote:
> With your help, everything seems to work now.
> My final subdirectory src/CMakeLists.txt looks like this:
>
> SET(FLTK_DIR "C:/Program Files/fltk-1.1.9/")
> SET(FLTK_BASE_LIBRARY "C:/Program Files/fltk-1.1.9/lib/")
> SET(FLTK_FORMS_LIBRARY "C:/Progra
Eh?
The files looks ok to me (in Sweden :-)
We are ahead of US (in time also :-) , but that shouldn't matter in this
case.
I unpacked the file, looked at the dates, and they are all from today around
noon (11:54).
Which means either you have to wait until after 11:54 or you have to touch
the fil
On Thu, Dec 30, 2010 at 08:08, Michael Hertling wrote:
> On 12/30/2010 11:33 AM, Ian Monroe wrote:
>> To create my QyotoConfig.cmake I need to know the full path of a
>> library so that I can set a variable like QYOTO_LIBRARY.
>>
>> This is pretty standard requirement right? Its what we're suppose
The rar file you have pointed us to, when extracted, yields "modified
time" stamps on the source files in the future. No matter how many
times you rebuild such a project, you will always get rebuild problems
with systems that base "modified-ness" on time stamps. Visual Studio /
msbuild is such a sy
The rar file you have pointed us to, when extracted, yields "modified
time" stamps on the source files in the future. No matter how many
times you rebuild such a project, you will always get rebuild problems
with systems that base "modified-ness" on time stamps. Visual Studio /
msbuild is such a sy
On 12/30/2010 11:33 AM, Ian Monroe wrote:
> To create my QyotoConfig.cmake I need to know the full path of a
> library so that I can set a variable like QYOTO_LIBRARY.
>
> This is pretty standard requirement right? Its what we're supposed to
> do in *Config.cmake's?
Yes.
> So anyways, how do I t
Am Donnerstag, den 30.12.2010, 11:01 +0100 schrieb Julia Jacobson:
> What grieves me is that the CMake code I had prepared in linux looked
> really nice (without any absolute paths and so on), but the file for
> Windows doesn't.
I think, the problem with FindFLTK is, that it has never been teste
On 12/30/2010 11:33 AM, Ian Monroe wrote:
> To create my QyotoConfig.cmake I need to know the full path of a
> library so that I can set a variable like QYOTO_LIBRARY.
>
> This is pretty standard requirement right? Its what we're supposed to
> do in *Config.cmake's?
>
> So anyways, how do I that?
On 12/30/2010 12:28 AM, j s wrote:
> I specified the full name to an so in CMAKE 2.8.1. Unfortunately it links
> against the versioned so name,
> libpython2.6.so.1.0
>
> instead of the exact name I specified.
> /usr/lib/libpython2.6.so
>
> SET (PYTHON_ARCHIVE /usr/lib/libpython2.6.so)
> TARGET_L
I think I managed to reproduce the problem, partially.
The file below contains a project which for me reproduces the problem when I
use msbuild.
F7 (Build->BuildSolution) works (builds only once, then next time, it does
nothing).
So there is something in the combination of CMake and msbuild which
To create my QyotoConfig.cmake I need to know the full path of a
library so that I can set a variable like QYOTO_LIBRARY.
This is pretty standard requirement right? Its what we're supposed to
do in *Config.cmake's?
So anyways, how do I that? The only target property that hasn't
returned NOTFOUND
Thanks for the explanation.
It appears I am at the mercy of how the python library was created. Since
python can never seem to commit to a stable ABI, I guess I'll have to be
wary of this issue.
Regards,
Juan
On Thu, Dec 30, 2010 at 3:19 AM, Michael Hertling wrote:
> On 12/30/2010 12:28 AM, j
With your help, everything seems to work now.
My final subdirectory src/CMakeLists.txt looks like this:
SET(FLTK_DIR "C:/Program Files/fltk-1.1.9/")
SET(FLTK_BASE_LIBRARY "C:/Program Files/fltk-1.1.9/lib/")
SET(FLTK_FORMS_LIBRARY "C:/Program Files/fltk-1.1.9/lib/")
SET(FLTK_GL_LIBRARY "C:/Program
Am Mittwoch, den 29.12.2010, 20:03 +0100 schrieb Julia Jacobson:
> Thanks for your answer. The file FindFLTK.cmake exists within my CMake
> installation, but I still get an error message:
> "CMake Error at C:/Program Files/CMake
> 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91
On 12/30/2010 12:28 AM, j s wrote:
> I specified the full name to an so in CMAKE 2.8.1. Unfortunately it links
> against the versioned so name,
> libpython2.6.so.1.0
>
> instead of the exact name I specified.
> /usr/lib/libpython2.6.so
>
> SET (PYTHON_ARCHIVE /usr/lib/libpython2.6.so)
> TARGET_L
22 matches
Mail list logo
