Eric Noulard wrote:
Is this a FIND_LIBRARY bug or
bad installation of the concerned lib?
Bad install of lib.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cma
KSpam wrote:
I agree that this is a Visual Studio issue; however, I am wondering if anyone
knows a workaround. I am not a Windows developer, but I figured that someone
on this list would have found a reasonable solution.
Sure. Don't use Visual Studio. Stick to nmake and a good editor like
Philip Lowman wrote:
I've never read that shared libraries are faster than static
executables. One would think that, if anything, all of the hoops the OS
has to run through to map all of the symbols would cause applications
that use shared libraries to be slower to startup then statically built
Brandon Van Every wrote:
> On 8/8/07, gga <[EMAIL PROTECTED]> wrote:
>> I know I can pass -D symbols to cmake to modify its behavior and that
>> windows also has its ugly CmakeSetup gui.
>
> "Ugly?" Geez, what are you, a candidate for Windows Aero or so
I'm currently using cmake for a variety of projects. Love it.
However, one feature I find myself missing more and more is one from
autotools configure scripts: AC_ARG_ENABLE().
That is, the ability to allow the configuration script (ie. cmake) to be
run with arbitrary flags to turn on or turn off
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
Timur Ivanov wrote:
>
> The problem is that common.cpp recompiled 3 times but I would like not
> to do that waste of time. Is it possible ?
No and Yes. No, cmake in general does not allow to do it easily or
reliably.
But your OS does. Make common.cpp into either a static or dynamic
library and
Does anyone have a simple gettext example being used with cmake?
I'm looking for something to automate both the .cpp -> .po conversion
and merging as well as the .po -> .mo creation.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
_
Andreas Schneider wrote:
>
> I've rewritten the FindBoost.cmake from scratch some time ago. And we
> have improved it at OpenWengo. I suggest to ship this version in CMake.
>
> http://cmake-modules.googlecode.com/svn/trunk/Modules/Boost/FindBoost.cmake
>
+1 for this. This is without a doubt th
I have a commercial application I'm developing and one feature of cmake
is throwing me off. Or, put another way, I'm not quite sure how I can
take advantage of it to make it work the way I want.
Basically, by default cmake creates executables using the -rpath
directive. This is great if you are
Brandon Van Every wrote:
>
> I guess this must be a problem with 3rd party libraries. I've never
> had this problem with libraries I built myself, either with the MinGW
> or the MSYS generators.
>
Maybe it is me. Whenever I compile libogg, libvorbis, etc. statically
or dynamically, the resulti
I'm writing a better Find module for using some libraries compiled
with MSYS under MSVC (FFMPEG to be more precise).
My problem is that FIND_LIBRARY() seems to only search for .lib files,
while MSYS static library files are named .a (even though they *are*
.lib files compatible with MSVC).
S
Bill Hoffman wrote:
>
> /usr/local is not part of any of the systems, and has to be explicitly
> added by the user in LD_LIBRARY_PATH.
Mostly true. Solaris and Linux's ld will also use ldconfig's paths when
searching for libraries.
> Also, the discovery of run time libraries might not always be
Bill Hoffman wrote:
>>
> So, I guess it depends on the UNIX system you are using... Say on
> Solaris or HPUX I would
> expect /usr to come before /usr/local, at least for the system
> compiler.
AFAIK, that's not right. HPUX and Solaris work just like every other
Unix distro, and /usr/local is
gga wrote:
> Currently, using cmake2.5, I am finding the lookup order of FIND_PATH /
> FIND_LIBRARY to be counter productive, so I'm wondering if this is a bug
> or intended behavior. If intended behavior, I would also want to know
> what's the proper way around it.
>
gga wrote:
> Currently, using cmake2.5, I am finding the lookup order of FIND_PATH /
> FIND_LIBRARY to be counter productive, so I'm wondering if this is a bug
> or intended behavior. If intended behavior, I would also want to know
> what's the proper way around it.
>
[EMAIL PROTECTED] wrote:
>
> Is there something that I can do to correct this? Am I doing something
> wrong? In digging around, I have not seen anything that indicates I need
> to do anything different when generating a VS .net 2003 solution from
> CMake.
>
This seems to be a bug in VS .net that
Currently, using cmake2.5, I am finding the lookup order of FIND_PATH /
FIND_LIBRARY to be counter productive, so I'm wondering if this is a bug
or intended behavior. If intended behavior, I would also want to know
what's the proper way around it.
Currently I have a project that may require some
Brandon Van Every wrote:
> CMake users: what source control systems are you using?
>
For my own projects, I've recently switched to git. After years of
using CVS, Subversion and a little of Perforce, git has clearly
surpassed them imo. I tried darcs and it was just too slow and painful
to use.
Oliver Kullmann wrote:
> The directory structure is "fractal" (or "recursive") and "dynamic", so
> for example modules have subdirectories Module/tests, containing generic
> tests for the components provided by the modules, where Module/tests might
> contain a tests-subdirectory itself for testing
Mathieu Malaterre wrote:
> It looks like you are on windows. Could you please try a nmake ("NMake
> Makefiles") build and do:
>
I'm on Linux (thank god), but have also a windows box with vnc.
I tried it on both, with cmake2.5 (CVS), but cmake2.4 should be the same
( I was using it before ).
> 1)
Mathieu Malaterre wrote:
> Example, your foo.i depends on bla.h. First time your configure,
> dependency will be right, for instance:
>
> Makefile:
> ...
> foo_wrap.cpp: foo.i
> foo_wrap.cpp: bla.h
> swig -o foo_wrap.cpp foo.i
>
> but now edit your foo.i file and add a new header file 'bar.h'. Th
Mathieu Malaterre wrote:
> This is a follow up on a previous post.
>
> I have written a simple dependency scanner macro (*). There is still
> one dependency missing:
> I need to reexecute the CMake macro every time the swig *.i file is
> modified.
>
> How do I do that ?
>
You don't. You add th
gga wrote:
> Filipe Sousa wrote:
>> you can use
>>
>> SET_TARGET_PROPERTIES(${target}
>> PROPERTIES LIBRARY_OUTPUT_DIRECTORY ...)
>>
>
> Really? That propery is not documented at www.cmake.org. However, it
> does not seem to work, either -- using cmak
Filipe Sousa wrote:
> you can use
>
> SET_TARGET_PROPERTIES(${target}
> PROPERTIES LIBRARY_OUTPUT_DIRECTORY ...)
>
Really? That propery is not documented at www.cmake.org. However, it
does not seem to work, either -- using cmake 2.4-patch 4.
The library still gets placed directly in the ${L
I'm trying to change the destination where some shared libraries are
created, trying to place them in subdirectories.
I need to have a macro, which in turn will modify the
LIBRARY_OUTPUT_PATH and create the new library in that new directory. I
have created such a beast. The debug output spits ou
I'm trying to change the destination where some shared libraries are
created, trying to place them in subdirectories.
I need to have a macro, which in turn will modify the
LIBRARY_OUTPUT_PATH and create the new library in that new directory. I
have created such a beast. The debug output spits ou
I'm trying to change the destination where some shared libraries are
created, trying to place them in subdirectories.
I need to have a macro, which in turn will modify the
LIBRARY_OUTPUT_PATH and create the new library in that new directory. I
have created such a beast. The debug output spits ou
I'm trying to change the destination where some shared libraries are
created, trying to place them in subdirectories.
I need to have a macro, which in turn will modify the
LIBRARY_OUTPUT_PATH and create the new library in that new directory. I
have created such a beast. The debug output spits ou
Josh Cherry wrote:
> 1. The slowness depends (in part, at least) on the fact that there is a
> cont.end() call for every iteration. If the code is changed to look like
> this:
>
> cont_end = cont.end()
> while it != cont.end():
> it.next()
>
> it is much faster. Of course,
Bill Hoffman wrote:
> Can you send a small example that does not work with nmake?
>
Not too small, I'm afraid. Is it okay to post a zip to the list? Or
to send you one?
I think I'm running into 2 or 3 issues, from what I can tell from the
verbose logs. Here's what I have:
Under NMake Makef
Nikita V. Borodikhin wrote:
> Hello, Gonzalo!
>
> I don't think using MSVC programs in GNU Makefile is a very good idea
> because they (linker in paticular) are not GNU-compatible by flags and
> arguments.
>
Thanks for the help. Still struggling, thou, due to nmake's crappy system.
Sorry, also
Nikita V. Borodikhin wrote:
> Hello, Gonzalo!
>
> I don't think using MSVC programs in GNU Makefile is a very good idea
> because they (linker in paticular) are not GNU-compatible by flags and
> arguments.
>
Thanks for the help. Still struggling, thou, due to nmake's crappy system.
Sorry, also
Okay, first time trying cmake under windows, porting a project from linux.
I'm trying to just create a simple cmake file for vc7.1.
I downloaded the pre-built cmake (cmake 2.4 - patch 6).
When I run CmakeSetup.exe, there's no option to allow me to select what
build to create, as shown in the we
and sure enough... two seconds after sending the email, I found out that
it is one of my own module definition setting -Wl,Bsymbolic.
Still... not sure what that does, so any help might be appreciated. I
seem to have borrowed the setting from the Makefile of the library I'm
linking against.
--
I'm using cmake with swig to wrap several libraries into different
modules (currently under Linux).
The modules are inter-related. That is, there's a swig base module that
needs to be loaded before the derived modules are and there are classes
in the derived module that inherit from the base mod
Philip Lowman wrote:
> I gave some thought towards working on adding first-class RPM and DPKG
> support to CPack tonight. I was just wondering if anyone has toyed
> around with this idea as of late or if this is something that the CMake
> project would even be interested in adding. Obviously, I'm
I'm looking for a macro or library to handle Flex/Bison files/depencies
from within cmake.
Anyone?
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailma
Hi. I have some code that creates out-of-source builds, by defining:
EXECUTABLE_OUTPUT_PATH
LIBRARY_OUTPUT_PATH
CMAKE_LIBRARY_PATH
CMAKE_BUILD_TYPE
This is working okay, but my problem is that cmake's build system is
still a tad simplistic for my taste. Even when I set all those
variables, the
Roman Yakovenko wrote:
> On 12/26/06, gga <[EMAIL PROTECTED]> wrote:
>
> Thanks for help. I know how to invoke native build system. What I
> don't know how to make
> it in "portable" way - I don't what to know what is the native build
> system. CMake
Roman Yakovenko wrote:
> Hi. It seems that I cannot to find answer for pretty simple question:
> how I can invoke native build system from\using CMake?
Short answer is that you invoke the native build system as usual (make,
nmake, etc).
Find attached a wrapper bash script I am using for cmake and
New to cmake but so far I love it.
First question I have is whether CMake is 32-bits/64-bits aware and
whether there is a way to set up a project to compile as either native
only, 32-bits only, 64-bits only or both.
So far I am unable to find anything of that nature in its built-in
configuration
Bill Hoffman wrote:
> Actually, it is not stored in the solution file. It is stored in the
> .ncb file. This is a binary file, that we do not know the format of.
Ah... I see, but...
If I am not mistaken, the MS IDE *has* to select some configuration as
the default when a project is loaded. I wou
Bill Hoffman wrote:
> With MS IDE, there is no way for
> us to change the default build type in one of the files we can
> generate.
Hmm... That's probably not right. Not sure about X code, but the MSVC
IDE most definitively saves out what's the default build whenever you
create a project from t
44 matches
Mail list logo
