On 6/15/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:
On 6/13/07, Clark J. Wang <[EMAIL PROTECTED]> wrote:
>
> I've tried GET_TARGET_PROPERTY but it does not work. The SUFFIX property
> returns NOTFOUND unless we explicitly set it by calling
> SET_TARGET_PROPERTIES.
I'd call that a bug. Wo
On Thursday 14 June 2007 16:36, Peter Visser wrote:
> I rather like the current (2.4.6) fine grained approach. In the past I
> experienced problems (run-time crashes) when stripping dll's, hence not
> stripping them better suits my specific case.
>
> Furtermore, the cvs version complains that it ca
I rather like the current (2.4.6) fine grained approach. In the past I
experienced problems (run-time crashes) when stripping dll's, hence not
stripping them better suits my specific case.
Furtermore, the cvs version complains that it cannot find the archive files
(which are not required in the p
On Thursday 14 June 2007 16:11, Peter Visser wrote:
> I just tried the current cvs HEAD, 7zip now works fine in my case.
> Thanks for the effort!
>
> However, the current cvs HEAD seems to ignore my 'STRIP_FILES' rule:
>
> SET(CPACK_STRIP_FILES "bin/*.exe")
>
> It now strips all files including dl
I just tried the current cvs HEAD, 7zip now works fine in my case.
Thanks for the effort!
However, the current cvs HEAD seems to ignore my 'STRIP_FILES' rule:
SET(CPACK_STRIP_FILES "bin/*.exe")
It now strips all files including dll's. This may be a cvs development
issue, or perhaps the command
On 6/14/07, Jesper Eskilson <[EMAIL PROTECTED]> wrote:
Is it really impossible to pass an option to the linker when creating a
static library?
It's not terribly difficult. But I thought I'd save you the learning
curve if it wasn't necessary.
Cheers,
Brandon Van Every
___
On 6/13/07, Clark J. Wang <[EMAIL PROTECTED]> wrote:
I've tried GET_TARGET_PROPERTY but it does not work. The SUFFIX property
returns NOTFOUND unless we explicitly set it by calling
SET_TARGET_PROPERTIES.
I'd call that a bug. Would you be so kind as to file it in the bug tracker?
http://www.
On Tuesday 15 May 2007 04:50, Peter Visser wrote:
> Thanks for the suggestion but still no 'sutable' ZIP program found.
>
> I have associated 7-Zip with .zip files (and all other possible extensions
> .tar .gz .rar and so on.) and added 7-Zip to the system path. But
> unfortunately CPack was not a
On Thursday 14 June 2007 12:10, Pierre Habouzit wrote:
...
> > Do you have access to a machine where you could set up a Nightly build ?
>
> No I don't, I'm not _that_ interested in Hurd, but Debian porters did
> wrote those patches to make it build properly, I just transmitted them.
Ok. Who sent
On Thu, Jun 14, 2007 at 10:29:40AM -0400, Alexander Neundorf wrote:
> On Wednesday 13 June 2007 06:33, Pierre Habouzit wrote:
> > NSIS also works for linux, it just has a small different command line
> > interface. Here is a patch from Michal Čihař to make it work.
>
> The patch as it is didn't
On Thu, Jun 14, 2007 at 10:12:40AM -0400, Alexander Neundorf wrote:
> On Wednesday 13 June 2007 06:32, Pierre Habouzit wrote:
> > Hurd does not have SA_SIGINFO, this patch is needed in order to build
> > cmake.
> >
> > Index: cmake-2.4.6/Source/kwsys/ProcessUNIX.c
> >
Hi Alexander,
On Thursday 14 June 2007 05:49, Raphael Cotty wrote:
> Hi,
> I started to add a new generator for VisualDSP++ project files.
> VisualDSP++ is a IDE for embedded processors (Blackfin, SHARC and
> TigerSHARC).
Cool :-)
It would be nice if we get this working, but this will be quite
Hi
On Thu, 14 Jun 2007 10:29:40 -0400
Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> The patch as it is didn't work, #include "cmCPackNSISGenerator.h" also had to
> be enabled, otherwise it didn't compile.
I didn't check it with HEAD, only with 2.4-patch 5.
> Can you please check that CMake c
On Wednesday 13 June 2007 06:33, Pierre Habouzit wrote:
> NSIS also works for linux, it just has a small different command line
> interface. Here is a patch from Michal Čihař to make it work.
The patch as it is didn't work, #include "cmCPackNSISGenerator.h" also had to
be enabled, otherwise it
On Wednesday 13 June 2007 06:32, Pierre Habouzit wrote:
> Hurd does not have SA_SIGINFO, this patch is needed in order to build
> cmake.
>
> Index: cmake-2.4.6/Source/kwsys/ProcessUNIX.c
> ===
> --- cmake-2.4.6.orig/Source/kwsys/Proc
Hi Raphael,
On Thursday 14 June 2007 05:49, Raphael Cotty wrote:
> Hi,
> I started to add a new generator for VisualDSP++ project files.
> VisualDSP++ is a IDE for embedded processors (Blackfin, SHARC and
> TigerSHARC).
Cool :-)
It would be nice if we get this working, but this will be quite some
On 6/14/07, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
Have a look at this page, it documents current CMake cvs HEAD:
http://www.cmake.org/Wiki/CMake_Cross_Compiling
I'm happy about questions, comments, ideas etc.
That's pretty cool. The 1st thing that springs to mind is not a CMake
issue
Alexander Neundorf wrote:
>> If I change z.h and z.cpp to add a new method, I usually don't get z.h
>> to work out of the box, but only realize it when compiling z.cpp .
>> What's annoying is that cmake will first compile a.cpp , b.cpp , c.cpp
>> and then only z.cpp .
>
> Try "make help" to get a
Is it planned to add the subj feature in cmake ? It might looks like
add_executable(test STATIC test.cpp)
--
Best regards,
Alexander mailto:[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman
On Wednesday 13 June 2007 17:59, Eric Noulard wrote:
> 2007/6/13, Jun Sun <[EMAIL PROTECTED]>:
> > I am very interested in the answer too. In general, I like to know
> > if cmake can support corss compiling and cross linking.
> >
> > I am new to cmake. I assume if cmake has the ablility to specify
On Thursday 14 June 2007 04:54, Philippe Fremy wrote:
> Hi,
>
> In my project, I have very often a pattern like this:
> a.cpp:
> #include "z.h"
>
> b.cpp:
> #include "z.h"
>
> c.cpp:
> #include "z.h"
>
>
> z.cpp:
> #include "z.h"
>
>
> If I change z.h and z.cpp to add a new method, I usually
On Thursday 14 June 2007 00:55, Clark J. Wang wrote:
> On 6/14/07, Clark J. Wang <[EMAIL PROTECTED]> wrote:
> > On 6/14/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> > > On 2007-06-14 08:58+0800 Clark J. Wang wrote:
> > > > Shared libs have different suffixes on different OSes. For example on
> >
It's "advanced" CMake use, but you might want to have a look at overriding
the CMake "rule variable" CMAKE_CXX_CREATE_STATIC_LIBRARY. (Or _C_ if it's C
source code.) You should be able to add some linker flags in there, although
they may apply to all static libraries built in the whole project. I'
Дана четвртак 14 јун 2007, Philippe Fremy је написао(ла):
> Hi,
>
> In my project, I have very often a pattern like this:
> a.cpp:
> #include "z.h"
>
> b.cpp:
> #include "z.h"
>
> c.cpp:
> #include "z.h"
>
>
> z.cpp:
> #include "z.h"
>
>
> If I change z.h and z.cpp to add a new method, I usua
Дана четвртак 14 јун 2007, Philippe Fremy је написао(ла):
> Hi,
>
> In my project, I have very often a pattern like this:
> a.cpp:
> #include "z.h"
>
> b.cpp:
> #include "z.h"
>
> c.cpp:
> #include "z.h"
>
>
> z.cpp:
> #include "z.h"
>
>
> If I change z.h and z.cpp to add a new method, I usua
Hi,
I started to add a new generator for VisualDSP++ project files.
VisualDSP++ is a IDE for embedded processors (Blackfin, SHARC and
TigerSHARC).
The first file to create is the project group xml file which looks like
that:
tata
Hi,
I started to add a new generator for VisualDSP++ project files.
VisualDSP++ is a IDE for embedded processors (Blackfin, SHARC and
TigerSHARC).
The first file to create is the project group xml file which looks like
that:
tata
Hi,
In my project, I have very often a pattern like this:
a.cpp:
#include "z.h"
b.cpp:
#include "z.h"
c.cpp:
#include "z.h"
z.cpp:
#include "z.h"
If I change z.h and z.cpp to add a new method, I usually don't get z.h
to work out of the box, but only realize it when compiling z.cpp .
On 6/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I think, I'missing a part of your reply. Could you please send it again?
Sorry about that.
If I remember correclty I was simply saying that :
no you can't. CMake does not expose those sub tasks, only the higher
ones: ADD_LIBRARY, ADD_EXEC
$ cvs di cmRemoveDefinitionsCommand.h
Index: cmRemoveDefinitionsCommand.h
===
RCS file: /cvsroot/CMake/CMake/Source/cmRemoveDefinitionsCommand.h,v
retrieving revision 1.3
diff -u -r1.3 cmRemoveDefinitionsCommand.h
--- cmRemoveDefiniti
There's already a but for it:
http://www.cmake.org/Bug/bug.php?op=show&bugid=5096
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
31 matches
Mail list logo
