On 30.07.08 22:49:25, David Boosalis wrote:
I have had no trouble using cmake to build kde executables, but have been
unable to use it successfully to build a shared library that my kde
application uses.
The library builds fine but it is missing all the symbols from my source
files.
You also need to add an install rule for your executable with
INSTALL(TARGETS ...
make install should work first, then make package will work too.
HTH,
David
On Thu, Jul 31, 2008 at 12:00 AM, Michael Masters [EMAIL PROTECTED]wrote:
I'm trying to get cpack working with our build and I'm a
Here the full description + patch
http://public.kitware.com/Bug/view.php?id=7433
Also, it could be nice too allow users to specify additionals options
to lupdate and lrelease command lines (-noobsolete, -nounfinished...).
Thx
--
Tanguy Krotoff [EMAIL PROTECTED]
+33 6 68 42 70 24
[Alan]
Hi Tonio:
See CMakeLists.txt at
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/bindings/python/
[Tonio]
Hi Alan,
Thanks again for your help !
I somehow managed to get a good-looking behavior in XCode, but I now have to
deal with a Fatal Python error: Interpreter not
Hello,
is it possible to add a custom target so that it would be visible in
all the subdirectories? i.e. i could do make custom_target in any of
the subdirs and it will build the deps from said directory and its
subdirs and then the custom_target itself?
--
Best Regards,
Piotr Jaroszyński
Hi,
I just found an issue while moc'ing one of our headers.
We have some #ifndeffed slots in that header which depend on -DWIN32.
A default qmake .pro project adds
-D_MSC_VER=1400 -DWIN32
on windows, MSVC8. The QT4_WRAP_CPP does not define WIN32.
(_WIN32 seems to be defined by, but I've no idea
I now have to deal with a Fatal Python error:
Interpreter not initialized (version mismatch?) while
trying to import the generated _example.so .
Ok, last problem solved, If it's not your code, it's probably the way you test
it :)
Some tip for those using osx (tiger) : the default python
Thanks Andreas.
YOur right I did not do the export, I never suspected it as qmake was working
just fine and I did not have to do a export with it. A bit of a hassle to go
back and add this, to all my classes, wish KDE didn't use gcc vixibility
feature. I am sure they have a reason for
George Neill wrote:
Hi All,
I have ran into a problem on Solaris (v10/SS12) with
CHECK_INCLUDE_FILES. I believe this is actually a bug in the header
file I am checking for but none-the-less it's a problem for me. I am
using cmake 2.4.8.
CHECK_INCLUDE_FILES(netinet/tcp.h HAVE_NETINET_TCP_H)
On 31.07.08 07:43:47, David Boosalis wrote:
YOur right I did not do the export, I never suspected it as qmake was working
just fine and I did not have to do a export with it. A bit of a hassle to
go back and add this, to all my classes, wish KDE didn't use gcc vixibility
feature. I am
Bill,
I have ran into a problem on Solaris (v10/SS12) with
CHECK_INCLUDE_FILES. I believe this is actually a bug in the header
file I am checking for but none-the-less it's a problem for me. I am
using cmake 2.4.8.
CHECK_INCLUDE_FILES(netinet/tcp.h HAVE_NETINET_TCP_H)
here's a quick
George Neill wrote:
Bill,
I have ran into a problem on Solaris (v10/SS12) with
CHECK_INCLUDE_FILES. I believe this is actually a bug in the header
file I am checking for but none-the-less it's a problem for me. I am
using cmake 2.4.8.
CHECK_INCLUDE_FILES(netinet/tcp.h HAVE_NETINET_TCP_H)
Hi,
I am running CMake 2.6 on an XP machine with
MS Visual Studio 2005 and am trying to compile
VTK cvs from the Visual Studio 2005 command prompt.
I am getting the following errors reported by
CMake:
CMake Error at CMakeLists.txt:1005 (ADD_SUBDIRECTORY):
add_subdirectory not given a binary
[EMAIL PROTECTED] wrote:
Hi,
I am running CMake 2.6 on an XP machine with
MS Visual Studio 2005 and am trying to compile
VTK cvs from the Visual Studio 2005 command prompt.
I am getting the following errors reported by
CMake:
CMake Error at CMakeLists.txt:1005 (ADD_SUBDIRECTORY):
Hi Bill,
RC 15 for 2.6.1 and using C instead of c:
cmake C:/C++/Source/VTK -GNMake Makefiles
but now I have:
Checking for ipv6 support. - no
RegularExpression::compile(): Nested *?+.
RegularExpression::compile(): Error in compile.
CMake Error at Utilities/MaterialLibrary/CMakeLists.txt:94
Hi,everyone
I'm a rookie of cmake. Now I want to use cmake to set up a cross-compiling
toolchain, the target platform is under ARM926's montavista linux v4 ( with
linux 2.6.10 kernel), What should I do to set up a cross-compiling toolchain,
so I can build my project to use in the target
[EMAIL PROTECTED] wrote:
Hi Bill,
RC 15 for 2.6.1 and using C instead of c:
cmake C:/C++/Source/VTK -GNMake Makefiles
but now I have:
Checking for ipv6 support. - no
RegularExpression::compile(): Nested *?+.
RegularExpression::compile(): Error in compile.
CMake Error at
On Wednesday 30 July 2008, Phil Smith wrote:
But then it complains that there's no CMakeLists.txt in the directory.
Anyway, I wasn't clear: the same person isn't likely to be doing z/OS and
Windows on the same machine. But since the same CMakeLists.txt is to be
used, I didn't want to
On Thursday 31 July 2008, 王汉斌 wrote:
Hi,everyone
I'm a rookie of cmake. Now I want to use cmake to set up a cross-compiling
toolchain, the target platform is under ARM926's montavista linux v4 ( with
linux 2.6.10 kernel), What should I do to set up a cross-compiling
toolchain, so I can build
When you say the executable, I assume you mean the object code? Note that
this is being compiled for a System z mainframe, so the object won't look much
like anything you've seen before. I can send it, but is that going to help?
I now understand the second problem. The issue is that System
And of course, as soon as I sent that, I realized the __SYSC__ not being
recognized is ALSO due to the ASCII/EBCDIC issue. So I'd say that if there's a
good way to tell cmake For all your try_compiles, use this flag, it should be
A Good Thing.
...phsiii
-Original Message-
From:
When compiling a binary with CMAKE_BUILD_TYPE as RelWithDebInfo, I
verify that the binary has debug symbols, but when I generate an rpm
using Cpack the debug symbols are lost. What's causing this?
--
Thanks,
Paul Hatfield
Software Engineer
BRIT Systems
1909 Hi-Line Dr. Suite A
Dallas, TX
Paul Hatfield wrote:
When compiling a binary with CMAKE_BUILD_TYPE as RelWithDebInfo, I
verify that the binary has debug symbols, but when I generate an rpm
using Cpack the debug symbols are lost. What's causing this?
rpm automatically runs strip on executables. It is not cmake doing this
On 2008-07-31 14:10- Piotr Jaroszy�~Dski wrote:
Hello,
is it possible to add a custom target so that it would be visible in
all the subdirectories?
My experience is that targets are actually available in all directories. The
only caveat is they must have been defined previously in the
is it possible to add a custom target so that it would be visible in
all the subdirectories?
My experience is that targets are actually available in all directories.
$ mkdir /tmp/test
$ cd /tmp/test
$ echo add_custom_target(bar) CMakeLists.txt
$ echo add_subdirectory(foo) CMakeLists.txt
$
Bill,
I must be missing something (or there's a bug in CheckIncludeFiles.cmake)
CHECK_INCLUDE_FILES(sys/types.h;netinet/tcp.h HAVE_NETINET_TCP_H)
SET(HAVE_NETINET_TCP_H ${HAVE_NETINET_TCP_H} CACHE INTERNAL netinet/tcp.h)
.
.
.
-- Looking for include files netinet/tcp.h
-- Looking for
George Neill wrote:
Bill,
I must be missing something (or there's a bug in CheckIncludeFiles.cmake)
CHECK_INCLUDE_FILES(sys/types.h;netinet/tcp.h HAVE_NETINET_TCP_H)
SET(HAVE_NETINET_TCP_H ${HAVE_NETINET_TCP_H} CACHE INTERNAL netinet/tcp.h)
.
.
.
-- Looking for include files netinet/tcp.h
--
On Thursday 31 July 2008, Phil Smith wrote:
When you say the executable, I assume you mean the object code? Note
that this is being compiled for a System z mainframe, so the object won't
look much like anything you've seen before. I can send it, but is that
going to help?
I can't tell
I have a release candidate (RC 16) for 2.6.1 ready for CMake.
If I do not get any complaints about this RC, it will become 2.6.1.
Again, if there are no major issues, I am going to make this 2.6.1 official.
Thanks.
The files can be found here:
http://www.cmake.org/files/v2.6/*RC-16*
The
There are executables with z/OS, but they're linkedited and certainly won't run
on Windows *at all*.
Since I've never had to understand the format of an object file on Windows, I'm
not sure how to answer the second question. Here's a screenshot of what the
CheckTypeSizeC object file looks
On Thursday 31 July 2008, Phil Smith wrote:
There are executables with z/OS, but they're linkedited and certainly won't
run on Windows *at all*.
Since I've never had to understand the format of an object file on Windows,
I'm not sure how to answer the second question. Here's a screenshot of
Sure, here are two files:
ctsc.fascii -- CheckTypeSizeC.c compiled with the Dignus -fascii option
ctsc.nofascii -- CheckTypeSizeC.c compiled without the Dignus -fascii option
So TRY_COMPILE not only compiles, but linkedits? That wasn't at all intuitive.
-Original Message-
From:
The ChangeLogs that I can find for CMake 2.4.8 and 2.6.0 all seem to
indicate that link lines being too long was fixed. Unfortunately, I'm
still seeing link lines that are too long and immediately fail out
because of it. Is there any place with more details on exactly *what*
was done to fix it? I
Did you set the CMAKE_EXECUTABLE_SUFFIX appropriately for z/OS ?
If by 'executable' you mean 'linked object', i.e., a .EXE if this was Windows,
then I *think* I have: in zosport.cmake is:
SET(CMAKE_LINKER linkit.bat)
SET(CMAKE_EXECUTABLE_SUFFIX OUT)
However, my linkit.bat starts with:
Andrew Sayman wrote:
The ChangeLogs that I can find for CMake 2.4.8 and 2.6.0 all seem to
indicate that link lines being too long was fixed. Unfortunately, I'm
still seeing link lines that are too long and immediately fail out
because of it. Is there any place with more details on exactly *what*
Hi List,
I am here trying to cross-compile a tiny demo project
with cmake 2.6.0.
When I ran cmake for the first time, link failed because
CMAKE_C_FLAGS was not used to compile cmTryCompileExec.
Then I modified nothing, but only ran cmake again.
CMAKE_C_FLAGS was used properly and link passed.
On Thu, Jul 31, 2008 at 10:30 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
Try 2.6.1 RC 16 and see if it is fixed.
What OS/Generator/Compiler are you using?
It didn't help. I'm using RHEL5.1 / Unix Makefiles / gcc-4.1.2
I may have actually stated the problem incorrectly. I'm building a
static
37 matches
Mail list logo
