2007/8/1, Andy Dingfelder [EMAIL PROTECTED]:
one small point I would add...
Instead of spending time getting cvs to integrate, I suspect more
eclipse folks prefer Subversion, which works very well in eclipse.
I'd rather use Subversion or even git too :))
The fact is my test case is on a
On Thursday 02 August 2007 05:34, Eric Noulard wrote:
...
Eclipse assume the top-level project folder MUST be under version control
which is not the case with the current approach of the Eclipse CDT
Generator which put .project and .cproject in the Build tree
(this is indeed a good idea for
I've coded my own solution for now to get Debians built, but was
hoping to move to CPack 2.6 once it's released.
But now I'm feeling some pressure to build RPM package as well.
Does anyone know: does CPack 2.6 not support RPMs for some major
technical reason, or has just no one had the time yet
On Wednesday 01 August 2007 17:24, Alexandru Ciobanu wrote:
Hi!
Please ignore my last message. According to bug 3100
info, this should have been fixed after 2.2.3.
I have just reproduced it with 2.4.7.
Check the attached test case. Here are the steps to reproduce:
1. cd build
2.
2007/8/2, Alexander Neundorf [EMAIL PROTECTED]:
On Thursday 02 August 2007 05:34, Eric Noulard wrote:
Moreover I think in-source built should be supported by the CDT Generator
in order to be consistent with other generator.
[...]
Yes, in-source builds should work and having Eclipse
2007/8/2, Christian Convey [EMAIL PROTECTED]:
I've coded my own solution for now to get Debians built, but was
hoping to move to CPack 2.6 once it's released.
But now I'm feeling some pressure to build RPM package as well.
The full packager pressure :))
Does anyone know: does CPack 2.6 not
Hi, Alexander!
Yes you are right, the sequence:
make
make preinstall
has the same effect - it builds the targets in the
EXCLUDED_FROM_ALL directory.
Regarding the bug reports, I've found one that
exposes the same issue, but it has status fixed,
and was filed for an older version ( 2.2.3):
On Aug 2, 2007, at 5:34 AM, Eric Noulard wrote:
Eclipse assume the top-level project folder MUST be under version
control
which is not the case with the current approach of the Eclipse CDT
Generator
which put .project and .cproject in the Build tree
(this is indeed a good idea for
On 8/2/07, Alexander Neundorf [EMAIL PROTECTED] wrote:
On Thursday 02 August 2007 10:01, Brandon Van Every wrote:
I'm not shocked. Anecdotally we've seen weird dependency errors for
Chicken on Linux, but since I'm not the Linux guy, we were never able
With static or shared libs ?
With
On 8/2/07, Alexandru Ciobanu [EMAIL PROTECTED] wrote:
Hi, Brandon!
I am on 32bit Linux. I've reproduced this on the
following systems (with 2.4.6 and 2.4.7):
- Red Hat Enterprise 5
- SUSE Linux Enterprise Server 10
- Ubuntu 7.04
On these systems cmake generates Makefiles.
I'm not
2007/8/2, Mike Jackson [EMAIL PROTECTED]:
On Aug 2, 2007, at 5:34 AM, Eric Noulard wrote:
Eclipse assume the top-level project folder MUST be under version
control
which is not the case with the current approach of the Eclipse CDT
Generator
which put .project and .cproject in the Build
On Thursday 02 August 2007 10:26, Mike Jackson wrote:
...
Also, If the .project/.cproject files are constantly regenerated then
every time I make a change to my project it is going to get over
written when cmake runs again. I have never really liked this in the
Xcode/Visual Studio use either.
On Aug 2, 2007, at 10:39 AM, Eric Noulard wrote:
[...]
Yes this a working solution but using this solution is not as
natural as it is for CMake CDT Generator since it still
needs to generate .project/.cproject in source dir and
the other generated stuff in Build dir.
When using
On 8/2/07, Eric Noulard [EMAIL PROTECTED] wrote:
2007/8/2, Alexander Neundorf [EMAIL PROTECTED]:
On Thursday 02 August 2007 05:34, Eric Noulard wrote:
Moreover I think in-source built should be supported by the CDT Generator
in order to be consistent with other generator.
Yes,
On Thursday 02 August 2007 10:01, Brandon Van Every wrote:
On 8/2/07, Alexandru Ciobanu [EMAIL PROTECTED] wrote:
Hi, Brandon!
I am on 32bit Linux. I've reproduced this on the
following systems (with 2.4.6 and 2.4.7):
- Red Hat Enterprise 5
- SUSE Linux Enterprise Server 10
-
When I create a new cmake area, the tests are failing since it cannot
find the 64bit version of our tools on linux.
Is there anyway to pass the -B option to C and C++ compiler during the
compiler testing phase?
Thanks,
Juan
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
On 8/2/07, Mike Jackson wrote:
On Aug 2, 2007, at 10:39 AM, Eric Noulard wrote:
Yes this a working solution but using this solution is not as
natural as it is for CMake CDT Generator since it still
needs to generate .project/.cproject in source dir and
the other generated stuff in Build
Hi!
I am not sure if any previous target related EXCLUDE_FROM_ALL
problems are linked with this one, but what I found is this:
- in CMakeFiles/Makefile2 ( which defines the preinstall
rule ) there is a section that processes the test/ directory.
I removed it and make install did work
Miguel A. Figueroa-Villanueva wrote:
1. integration with the Microsoft tools.
Bill mentioned that we can compile with the VS Express (or any VS
version) compiler and debug with cygwin gdb, right? Can somebody point
me in the direction on how to do this? I seem to recall that it wasn't
with the
2007/8/2, Miguel A. Figueroa-Villanueva [EMAIL PROTECTED]:
start rambling
I'm not sure where the problem is, but I'm certainly developing a
love/hate relationship with eclipse ;) On the one hand it is a great
tool, although a memory hog, that has quite a nice interface and great
flexibility.
Juan Sanchez wrote:
When I create a new cmake area, the tests are failing since it cannot
find the 64bit version of our tools on linux.
Assuming they are installed in /usr/local or /usr, one should expect
that to be automatic. That being said...
Is there anyway to pass the -B option to C
Hello gga,
Unfortunately, the ADD_DEFINITIONS aren't being used in the initial
tests being done by cmake. What I've found is that I need to put the
location of the 64bit linker utils needed by g++ in my PATH. In this
instance, its calling the wrong assembler. The assembler is implicitly
called
Juan Sanchez wrote:
Hello gga,
Unfortunately, the ADD_DEFINITIONS aren't being used in the initial
tests being done by cmake. What I've found is that I need to put the
location of the 64bit linker utils needed by g++ in my PATH. In this
instance, its calling the wrong assembler. The
Hi,
I'm trying to build CMake 2.4.7 on Solaris 10. (Before I go on, I am a
total and complete newbie to Solaris, so if it's something stupid I'm
doing, I'm not suprised.
Anyway, I have a new Solaris 10 virtual machine in which I've set up
the standard development tools which I obtained from
On Thursday 02 August 2007 13:02, Seth Grover wrote:
Hi,
I'm trying to build CMake 2.4.7 on Solaris 10. (Before I go on, I am a
total and complete newbie to Solaris, so if it's something stupid I'm
doing, I'm not suprised.
...
Source/kwsys/CMakeFiles/cmsys.dir/CommandLineArguments.o
[ 4%]
On Thursday 02 August 2007 13:01, Alexandru Ciobanu wrote:
Hi!
I was able to find and correct the problem.
I have used the 2.4.7 release sources.
Here is the trivial patch ( also attached):
--- cmake-2.4.7/Source/cmGlobalUnixMakefileGenerator3.cxx
2007-07-16 17:12:31.0 -0400
+++
On Wednesday 01 August 2007 18:53, Juan Sanchez wrote:
Is it possible to get the include paths from ADD_DIRECTORIES into a
custom command? I need to pass along the include path for a special
swig invocation.
Does get_directory_property( incDirs INCLUDE_DIRECTORIES) what you want ?
Alex
Alexander Neundorf wrote:
Please run make VERBOSE=1 then we will see more.
Also, does the binary not work for some reason?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
It looks like it should work.
Thanks,
Juan
Alexander Neundorf wrote:
On Wednesday 01 August 2007 18:53, Juan Sanchez wrote:
Is it possible to get the include paths from ADD_DIRECTORIES into a
custom command? I need to pass along the include path for a special
swig invocation.
Does
Hi!
I was able to find and correct the problem.
I have used the 2.4.7 release sources.
Here is the trivial patch ( also attached):
--- cmake-2.4.7/Source/cmGlobalUnixMakefileGenerator3.cxx
2007-07-16 17:12:31.0 -0400
+++ cmake-2.4.7-x/Source/cmGlobalUnixMakefileGenerator3.cxx
Hate to reply to my own email, but...
Holy crap. I just ran the bootstrap command on linux (I haven't built
from source on linux, just installed from the repo's before) and it's
MUCH longer than what I'm getting on solaris. So maybe it's not the
make that's the problem for me, but the
Hi Bill,
I was able to add CMAKE_CXX_FLAGS to my initial cache file and it
worked. Thanks for the clarification.
Thanks,
Juan
Bill Hoffman wrote:
Juan Sanchez wrote:
Hello gga,
Unfortunately, the ADD_DEFINITIONS aren't being used in the initial
tests being done by cmake. What I've found
I think there is something missing from the patch. It doesn't change the
behavior at all. I'm assuming this is due to the functions not being registered
as the default fill functions.
When I tried to run cmake-fill-comment-paragraph explicitly on a long comment
line, it got stuck in what
Solved!
After looking more closely at the verbose output you suggested I
generate, I then google CMAKE_AR and realized that ar was not in my
path (it was in /usr/ccs/bin/, which is not in my path -- like I said,
I know very little about solaris). I included it in my path, ran
everything again,
Hi, Alex!
You are right. The patch does not do the right thing.
I just observed that it also completely removes the
preinstall rule for excluded directories.
So make install insde those dirs will fail because there
is no preinstall.
Alex
Alexander Neundorf wrote:
On Thursday 02 August 2007
2007/8/2, Mike Jackson [EMAIL PROTECTED]:
On Aug 2, 2007, at 10:39 AM, Eric Noulard wrote:
When using out-of-source build with CMake
(including Visual Studio) the project file is generated in the
Build Tree
not the Source Tree.
LIke I said, Eclipse is NOT like other IDEs and therefor
Also, does the binary not work for some reason?
-Bill
Well, that was my original intent, but
http://www.cmake.org/HTML/Download.html doesn't offer a binary for
Solaris 10 x86, and the one at sunfreeware.com installed but core
dumped when I tried to run it.
No worries, though, it's working
Am Donnerstag 02 August 2007 19:26 schrieb Alexander Neundorf:
I guess the EXCLUDE_FROM_ALL targets will then also not be relinked if they
are installed, right ?
Maybe for EXCLUDE_FROM_ALL targets the relinking should happen when the
target gets built, not when it's installed ?
Or evaluate
On 8/2/07, Bill Hoffman [EMAIL PROTECTED] wrote:
JD Smith wrote:
set( f this; ...is: a; test)
MESSAGE(${f})
STRING(REPLACE is was f ${f})
MESSAGE(${f})
Probably to do with the syntax for lists, but is there a way to avoid
STRING(REPLACE from eating semi-colons? I'm trying to
set( f this; ...is: a; test)
MESSAGE(${f})
STRING(REPLACE is was f ${f})
MESSAGE(${f})
Probably to do with the syntax for lists, but is there a way to avoid
STRING(REPLACE from eating semi-colons? I'm trying to replace a sed
call with pure CMAKE, but in text replacing on an XML file, it's
JD Smith wrote:
set( f this; ...is: a; test)
MESSAGE(${f})
STRING(REPLACE is was f ${f})
MESSAGE(${f})
Probably to do with the syntax for lists, but is there a way to avoid
STRING(REPLACE from eating semi-colons? I'm trying to replace a sed
call with pure CMAKE, but in text replacing on an
On Aug 2, 2007, at 7:41 PM, Bill Hoffman wrote:
JD Smith wrote:
set( f this; ...is: a; test)
MESSAGE(${f})
STRING(REPLACE is was f ${f})
MESSAGE(${f})
Probably to do with the syntax for lists, but is there a way to
avoid STRING(REPLACE from eating semi-colons? I'm trying to
replace a
42 matches
Mail list logo
