already works), now before I file a bugreport: Did I miss
anything that makes Debug not unusable (except for backtraces)?
Andreas
--
You have no real enemies.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On 19.09.07 08:32:22, Bill Hoffman wrote:
> Andreas Pakulat wrote:
> >Hi,
> >
> >yesterday I noticed that the Debug buildtype has the same problems as
> >the --enable-debug option in autohell. Its not possible to properly
> >debug an application that has been
ta files into that directory and the binary into
/usr/local/yourapp/bin when you run make install. That works the same
way as configure's --prefix option. (The default is /usr/local IIRC).
Andreas
--
Chicken Little was right.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
g mailinglist. This list is for users of
cmake, not nmake or gnu-make. CMake is a cross-platform buildtool that
can generate nmake or gnu-make Makefiles, those are not supposed to be
changed manually after generation.
Andreas
--
Your heart is pure, and your mind clear, and your soul devout.
__
ith such
scripting-language buildsystems like CMake is that you can't fit it into
a GUI, at least not for the "generic" case.
Andreas
--
Your society will be sought by people of taste and refinement.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
is:
What source files are used in which target.
Whats the type of each target (library, executable).
What other libraries does a target link to.
What include dirs are needed for each subdirectory.
Special compiler flags for certain targets/subdirs.
Andreas
--
You're definitely on their list
and debug. So its not a
problem to have
builddir/debug
builddir/release
and call cmake in each one using the right build type.
Andreas
--
Your supervisor is thinking about you.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On 23.09.07 20:50:48, Christian Buhtz wrote:
> Andreas Pakulat schrieb:
> >You can't. You specify the build type during cmake-time, using
> >-DCMAKE_BUILD_TYPE=Debug|Release|... And thats quite ok
>
> So I need to create makefile like this:
No. CMake will create the ma
2-make manualy?
It works the same way as other make tools, just run "mingw32-make" in
the build directory after having run cmake.
Andreas
--
Don't you wish you had more energy... or less ambition?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On 24.09.07 04:18:22, Christian Buhtz wrote:
> Andreas Pakulat schrieb:
> >It works the same way as other make tools, just run "mingw32-make" in
> >the build directory after having run cmake.
>
> So I was right to say that I have to generate a makefile for each b
ut
don't provide headers for the library and don't give it a SOVERSION so
people won't link against it.
Andreas
--
A gift of a flower will soon be made to you.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On 26.09.07 09:19:06, Bill Hoffman wrote:
> Andreas Pakulat wrote:
> >On 26.09.07 15:13:38, Dizzy wrote:
> >
> >>On Wednesday 26 September 2007 14:55:52 Joachim Ziegler wrote:
> >>
> >>>Hello,
> >>>
> >>>I have two
On 26.09.07 10:03:08, James Bigler wrote:
> Has anyone any examples of building a compiler (of sorts) and using that
> compiler to generate code then integrated into another CMake target?
Look at Qt apps that use cmake and dbus. Or any kde application and
KDE's automoc-compile
On 26.09.07 11:25:21, James Bigler wrote:
> On Sep 26, 2007, at 11:03 AM, Andreas Pakulat wrote:
>
> >On 26.09.07 10:03:08, James Bigler wrote:
> >>Has anyone any examples of building a compiler (of sorts) and using that
> >>compiler to generate code then integr
But cmake looks in */lib
> directories where some x86 libs are present that are not present for the
> x86-64 case.
> The question here is even worse - which one is the native one?? lib or lib64??
> And which ones should cmake accept?
I think there's a way to tell CMake to eith
something else, but
fact is that pkconfig is unusable in _plain_ win32 (without msys, which
I think creates problems when using cmake).
And a link from the pkgconfig website claiming it works properly is not
really a proof ;)
Andreas
--
Things will be bright in P.M. A cop will shine a
y ignores
pkgconfig on win32 in its CMake FindXXX modules (its used extensively on
*nix and also MacOS)
> To a Windows native developer this tool smells bad.
I'm not a real win32 developer (just doing my part in porting a kde4 app
to win32) and it smells to me as bad as it smells to you ;)
Andreas
--
Are you making all this up as you go along?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On 27.09.07 16:07:46, Alan W. Irwin wrote:
> On 2007-09-27 21:53+0200 Andreas Pakulat wrote:
> >No it doesn't work properly on win32 - AFAIK. Thats the reason why all
> >cmake FindXXX modules for KDE4/win32 don't use pkgconfig. I'm not sure
> >wether it was
On 28.09.07 07:47:50, Mathias Froehlich wrote:
>
> Hi,
>
> On Thursday 27 September 2007 15:53, Andreas Pakulat wrote:
> > Just to state the obvious: Thats backwards compared to what distro's
> > have these days. */lib is always the native libs and then you have
On 28.09.07 03:23:01, Hendrik Sattler wrote:
> Am Freitag 28 September 2007 schrieb Brandon Van Every:
> > On 9/27/07, Andreas Pakulat <[EMAIL PROTECTED]> wrote:
> > > I'm reporting 2nd hand information from people that have long-time
> > > experience with
On 28.09.07 03:31:26, Hendrik Sattler wrote:
> Am Freitag 28 September 2007 schrieb Andreas Pakulat:
> > On 27.09.07 16:07:46, Alan W. Irwin wrote:
> > > On 2007-09-27 21:53+0200 Andreas Pakulat wrote:
> > > >No it doesn't work properly on win32 - AFAIK. Th
On 28.09.07 11:23:15, Alan W. Irwin wrote:
> On 2007-09-28 11:51+0200 Andreas Pakulat wrote:
>
> >On 28.09.07 03:31:26, Hendrik Sattler wrote:
> >>I only used it with msys so far and it's working, there, using the GLIB dll
> >>and the provided pre-compiled pkg
No need to Cc me, I'm reading the list.
On 28.09.07 13:37:08, Alan W. Irwin wrote:
> On 2007-09-28 21:32+0200 Andreas Pakulat wrote:
> >Well, anyway, tried it and there we are, unix-paths in the output so
> >there's no way these flags can be used in a win32 native enviro
work on win32. CMake works on win32 natively,
without any posix stuff so a builddir setup by CMake should and does
behave like a native win32 build, without any of the posix-specialties
that msys provides.
Andreas
--
Tonight you will pay the wages of sin; Don't forget to leave a tip.
__
On 20.10.07 06:17:56, Gonzalo Garramuño wrote:
> Andreas Pakulat wrote:
> >But exactly that is not supposed to happen.
>
> Why not? Maybe I was not clear:
Or maybe I didn't read that part of the thread :)
> cmake2.5 has a "MSYS Makefile" generator.
Aah, ok.
LUGINS_DIR variable should be removed again from
FindQt4.cmake, or at least it should have a big fat warning that users
might end up with installing into two locations, where they don't have
write access to one of them.
Andreas
--
Lady Luck brings added income today. Lady friend takes
the support is already good enough to open a CMake
project, give it a builddir, let it run cmake (if that hasn't been done
in the builddir) and then you'll get a list of all cached variables from
CMakeCache.txt with editing possibilities. You can even very easily
switch between multiple build
ur source tree. And also
with CMake you can't have a builddir containing multiple output files
frmo different configuration. As soon as you switch from release to
debug build everything gets rebuild anyway.
So, I think the answer to your question is: no thats not possib
che. Not your everyday scenario,
still happens from time to time.
Andreas
--
Celebrate Hannibal Day this year. Take an elephant to lunch.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
new project files aren't used for the build.
How exactly should cmake fix a bug in Visual Studio? As far as I
understood this thread the problem is that VS doesn't get that its
project files have changed and thus doesn't reload them. I suggest to
contact your MS support contac
, IMHO), and/or documenting that it is broken.
So far you're the only one claiming that (in this thread), I suggest to
come up with a small sample project where changing the CMakeLists.txt
doesn't trigger a cmake run. If you've got that you can file a bugreport
against cmake.
Andre
On 01.11.07 14:29:02, Jesper Eskilson wrote:
> Andreas Pakulat wrote:
> > On 01.11.07 10:49:12, Jesper Eskilson wrote:
> >> In any case, the automatic regeneration of project files *does* *not*
> >> *work*, and my question was simply if there was a plan for either do
On 01.11.07 15:08:19, Jesper Eskilson wrote:
> Andreas Pakulat wrote:
>
> > ,
> > | On 01.11.07 10:49:12, Jesper Eskilson wrote:
> > | In any case, the automatic regeneration of project files *does*
> > | *not*
> > | *work*, and my question was s
OUTPUT_PATH and set it to ${CMAKE_BINARY_DIR}/bin. The same
can be done for LIBRARY_OUTPUT_PATH to have libs in /lib.
Andreas
--
Afternoon very favorable for romance. Try a single person for a change.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
equally well by the c pre processor.
>
> Since each C/C++ compiler has a cpp, wouldn't it be good to adopt the
> dependency scanner to use cpp underneath?
Indeed, I wonder why cmake doesn't use the -M options for cpp for
this...
Andreas
--
You are always busy.
___
e useful cmake variables
[1] and a small projects which shows you how to works with cmake [2]. And
maybe you should know that there is an IRC channel #cmake on freenode :)
The manpage and the wiki link was enough for me to get started.
-- andreas
[1] http://www.cmake.org/Wiki/CMa
se. Unfortunately the cmake manpage
lacks a tad bit there, as it only talks about installing into
/lib and /bin in the section about "install". However
the old and deprecated commands INSTALL_TARGETS, INSTALL_FILES and so on
have a link between installation prefix and the variable thats act
target, for installing locally
> after completion of a build.
CPack uses that installation-information to generate its packages
(AFAIK, never used it myself). So if you manage to write the needed
install-commands for anything you want in the packages, a simple run of
CPack should give you the
On 16.11.07 21:05:50, Stephen Collyer wrote:
> Manuel Klimek wrote:
> > Hi,
> >
> > have you tried using ${QT_INCLUDE_DIR} and ?
>
> Yes. It gives the same error. Thanks for the suggestion though.
run make VERBOSE=1 to check which directories are really given to gc
t;make" again and have the makefiles be updated anyways.
You don't need to do anything extra. Calling cmake with -D... writes
that variable and its value into the CMakeCache.txt and thus the next
run of cmake issued via a simple make will use that variable. Same goes
for running "cm
problem. Hence your hack: tell
> cmake explicitly where to look and all is well.
Usually this indicates a lack of cross-platform tests for the library in
question. You should open a bugreport with Kitware to get this fixed.
Unless of course you're not using the official
ages is a tad bit
strange, usually you get /lib + /include for
stuff that comes from *nix originally.
So yes, file a bugreport in the cmake bugtracker.
Andreas
--
Cold hands, no gloves.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
curl.dll file.
> The original code was:
A .dll is not enough on win32 to use the library. Make sure you also
have either a .def file with the exported symbols or a static import
lib (for MSVC these are called XXX.lib IIRC, for mingw its usuall
.dll.a)
I don't know wether find_library also lo
link to, i.e.:
add_library(modC_foo)
target_link_libraries(modC_foo modA_bar modB_baz)
Then CMake will figure out the right order of building the libraries in
modules A and B for you.
Andreas
--
Try to get all of your posthumous medals in advance.
_
u want variable arguments. Look in the MACRO docs for ARGC, ARGV, and ARGN.
And it might be easier if you switch positions for option and file-list.
Andreas
--
A tall, dark stranger will have more fun than you.
___
CMake mailing list
CMake@cmake.or
t exist , libb will be built before libc??? I know cmake
> doesn't do this
No, cmake does exactly that. If libc links to liba and libb those two
will be built before libc. CMake takes care of doing that.
Andreas
--
People are beginning to notice you. Try
On 03.12.07 11:57:42, [EMAIL PROTECTED] wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > ] On Behalf Of Andreas Pakulat
> > Sent: Monday, December 03, 2007 11:52 AM
> > To: cmake@cmake.org
> > Subj
round that.
That last part is not correct anymore. Recent releases of Qt4 Opensource
for windows include msvc support, at least for building. (recent = 4.3.2
and younger, see the changelog)
Andreas
--
There was a phone call for you.
___
CMake mailing lis
works" experience is a bad
requirement and setting the bar higher unnecessarily.
Having a simple GUI to add a lib/app target and a couple of source files
to that and writing a CMakeLists.txt for the result isn't really going
to hurt anybody - IMHO.
Andreas
--
You are a bundle of energy, alw
rary (Hello hello.cxx hello.h)
>
> get_target_property(FILE Hello LOCATION)
>
> message("Lib is called: ${FILE}")
>
>
>
> Run cmake on this and I get the output:
You forgot the cmake output, but I see the same thing here. CMake 2.4.7.
Andreas
--
You will h
C is not defined
it can't be used in a function call.
Andreas
--
You will be surprised by a loud noise.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On 21.12.07 18:46:53, Andreas Pakulat wrote:
> Hi,
>
> trying to build kdewin32 fails because CMake's CHECK_SYMBOL_EXISTS tries
> to compile the following source:
>
> ,
> | #include
> |
> | void cmakeRequireSymbol(int dummy,...){(void)dummy;}
> | in
On 21.12.07 13:54:45, Clinton Stimpson wrote:
> On Dec 21, 2007, at 11:07 AM, Andreas Pakulat wrote:
>> On 21.12.07 18:46:53, Andreas Pakulat wrote:
>>> Hi,
>>>
>>> trying to build kdewin32 fails because CMake's CHECK_SYMBOL_EXISTS
e git. It's much better than the pain of cvs
or svn.
>
> Regards,
> rod
-- andreas
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
--
http://www.cynapses.org/ - cyb
#x27; if doxygen is found.
-- andreas
--
http://www.cynapses.org/ - cybernetic synapses
signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
ber of source files.
Andreas
--
You will soon forget this.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
bin dir for the compiler.
I may be just overlooking something, so if you've found the place then
please let me know.
But I can confirm that CMake does find cl in a pretty "empty"
environment. (one that only has standard paths and the cmake binary dir
in it)
Andreas
--
You may
stinks. I've got to see
> about setting up the SSH authorized keys.
It is possible to use webdav for pushing to git, but it isn't recommended.
http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
-- andreas
--
http://www.cynap
ES, wxWidgets_FOUND, wxWidgets_LIBRARIES. It should be
> better if they were BOOST_FOUND, WXWIDGETS_FOUND etc.
For much better FindBoost.cmake module take a look at
http://cmake-modules.googlecode.com/svn/trunk/Modules/Boost/FindBoost.cmake
-- andreas
--
http://www.cynapses.o
On 14.01.08 23:40:39, Andreas Schneider wrote:
> Rodolfo Schulz de Lima wrote:
> > Hi, I'd like to comment on the Find*.cmake variable naming procedure
> > adopted by cmake. Right now I have to look at some Find*.cmake files to
> > see what are the output variables
Andreas Pakulat wrote:
> On 14.01.08 23:40:39, Andreas Schneider wrote:
>> Rodolfo Schulz de Lima wrote:
>>> Hi, I'd like to comment on the Find*.cmake variable naming procedure
>>> adopted by cmake. Right now I have to look at some Find*.cmake files to
>>&g
On 15.01.08 11:40:46, Andreas Schneider wrote:
> Andreas Pakulat wrote:
> > On 14.01.08 23:40:39, Andreas Schneider wrote:
> >> Rodolfo Schulz de Lima wrote:
> >>> Hi, I'd like to comment on the Find*.cmake variable naming procedure
> >>> adopted
Rodolfo Lima wrote:
> Andreas Schneider escreveu:
>
>> For much better FindBoost.cmake module take a look at
>
> I see that there's no way to specify which version you might need. Yes,
> you could check BOOST_VERSION *after* FindBoost returns, but this don't
>
" replacement.
Andreas
--
Avoid reality at all costs.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On 15.01.08 12:05:36, Brandon Van Every wrote:
> On Jan 15, 2008 11:46 AM, Andreas Pakulat <[EMAIL PROTECTED]> wrote:
> > On 15.01.08 11:37:12, Brandon Van Every wrote:
> > > I'm unclear. What is the strategic purpose of CBS?
> >
> > If I understood co
s/viewvc/Task_7/MXADataModel/Resources/MXAFindBoost.cmake?view=markup
That server doesn't respond here, or rather it times out after a couple
of minutes. Can you just append it to a mail?
Andreas
--
You will always get the greatest recognition for th
On 15.01.08 15:08:06, Mike Jackson wrote:
I know I'm a PITA, but a please a real attachment. Your mail client
inserted linebreaks in a lot of files and I don't see myself fixing that
manually - the file is really too large ;)
Andreas
--
You own a dog, but you can only
Hi,
does anybody know of a "built-in" way of determining the c++ compiler
version? Specifically for GNU gcc?
Or do I have to run CMAKE_CXX_COMPILER with --version and extract the
information myself?
Andreas
--
You are fairminded, just
Andreas Pakulat wrote:
> Hi,
>
> does anybody know of a "built-in" way of determining the c++ compiler
> version? Specifically for GNU gcc?
>
> Or do I have to run CMAKE_CXX_COMPILER with --version and extract the
> information myself?
http://dev.openwengo.org/t
On 16.01.08 12:25:53, Andreas Schneider wrote:
> Andreas Pakulat wrote:
> > does anybody know of a "built-in" way of determining the c++ compiler
> > version? Specifically for GNU gcc?
> >
> > Or do I have to run CMAKE_CXX_COMPILER with --version and extract
for the oracle9 and
the other for the oracle10 build. Building in oracle9 builddir should
set ORACLE9_FOUND to TRUE, and it should be set to FALSE when building
oracle10 stuff.
Andreas
--
Chicken Little was right.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
aneously.
Then you need to use two PROC_BIN variables, probably also including the
version number and use two add_custom_command invocations.
CMake simply doesn't support reading cmake variables out of the target
properties, except for those it knows and are defined in the cmake
manual.
Andreas
--
n the
same subdir inside your buildtree, by using LIBRARY_OUTPUT_PATH and
EXECUTABLE_OUTPUT_PATH.
Andreas
--
Caution: breathing may be hazardous to your health.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
On 14.01.08 23:40:39, Andreas Schneider wrote:
> Rodolfo Schulz de Lima wrote:
> > Hi, I'd like to comment on the Find*.cmake variable naming procedure
> > adopted by cmake. Right now I have to look at some Find*.cmake files to
> > see what are the output variables
Andreas Pakulat wrote:
> On 14.01.08 23:40:39, Andreas Schneider wrote:
>> Rodolfo Schulz de Lima wrote:
>>> Hi, I'd like to comment on the Find*.cmake variable naming procedure
>>> adopted by cmake. Right now I have to look at some Find*.cmake files to
>>&g
On 17.01.08 23:41:54, Andreas Schneider wrote:
> Andreas Pakulat wrote:
> > On 14.01.08 23:40:39, Andreas Schneider wrote:
> >> Rodolfo Schulz de Lima wrote:
> >>> Hi, I'd like to comment on the Find*.cmake variable naming procedure
> >>> adopted
On 18.01.08 22:39:17, Alexander Neundorf wrote:
> On Friday 18 January 2008, Andreas Schneider wrote:
> > It is
> >
> > /opt/local
>
> This one is already, at least cmake cvs.
Do you mean that cmake cvs always looks in /opt/local unless
NO_DEFAULT_PATHS are specified?
Andreas Pakulat wrote:
> On 17.01.08 23:41:54, Andreas Schneider wrote:
>> Andreas Pakulat wrote:
>>> On 14.01.08 23:40:39, Andreas Schneider wrote:
>>>> Rodolfo Schulz de Lima wrote:
>>>>> Hi, I'd like to comment on the Find*.cmake variable na
Hi,
apparently the FindBoost.cmake I attached to
http://www.cmake.org/Bug/view.php?id=6257
isn't quite perfect - actually not even close. The last few days I've
worked with Andreas Schneider to make it work on his and my own system.
However thats just two, I'd like to get so
Andreas Pakulat wrote:
> Hi,
Hello,
>
> apparently the FindBoost.cmake I attached to
> http://www.cmake.org/Bug/view.php?id=6257
>
> isn't quite perfect - actually not even close. The last few days I've
> worked with Andreas Schneider to make it work on his
On 20.01.08 01:36:26, Hendrik Sattler wrote:
> Am Sonntag 20 Januar 2008 schrieb Andreas Schneider:
> > Andreas Pakulat wrote:
> > > Hi,
> >
> > Hello,
> >
> > > apparently the FindBoost.cmake I attached to
> > > http://www.cmake.org/Bug/view.
On 20.01.08 01:36:26, Hendrik Sattler wrote:
> Am Sonntag 20 Januar 2008 schrieb Andreas Schneider:
> > Andreas Pakulat wrote:
> > > Hi,
> >
> > Hello,
> >
> > > apparently the FindBoost.cmake I attached to
> > > http://www.cmake.org/Bug/view.
On 20.01.08 11:15:33, Hendrik Sattler wrote:
> Am Sonntag 20 Januar 2008 schrieb Andreas Pakulat:
> > On 20.01.08 01:36:26, Hendrik Sattler wrote:
> > > Am Sonntag 20 Januar 2008 schrieb Andreas Schneider:
> > > > Andreas Pakulat wrote:
>
On 20.01.08 13:15:47, Hendrik Sattler wrote:
> Am Sonntag 20 Januar 2008 schrieb Andreas Pakulat:
> > On 20.01.08 11:15:33, Hendrik Sattler wrote:
> > > http://www.boost.org/more/getting_started/windows.html#get-boost
> > > (slightly wrong link in there) ->
> &g
On 20.01.08 14:05:17, Rodolfo Lima wrote:
> Andreas Pakulat escreveu:
>
> > If you encounter any errors please reply to this mail with the cmake
> > error message and if you want to invest the time a patch to fix the
> > problem :)
>
> Works for me in a gent
his message. You could do:
Yeah, currently it simply finds the "oldest" version.
Luckily we don't need that complex cmake code as the Boost_VERSION is a
plain number and can be compared to another plain number in a much
easier way :)
Andreas
--
Better hope the life-inspector do
-c++-runtime" and without writing tons of CMake
code.
I'll try to look into that tomorrow. Thanks for the link and the hints.
Andreas
--
Don't you feel more like you do now than you did when you came in?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Rodolfo Lima wrote:
> Again, it would be good if we could choose which version to detect. If I
> have 1.33.0 and 1.34.1, I want my application to use 1.34.1 and beyond.
You can simply overwrite the variable _boost_TEST_VERSIONS.
-- andreas
--
http://www.cynapses.org/ - cybe
s boost-z.xx.y, only z_xx_y
and the latter is definetly what boost itself uses.
The real problem is actually building up the "right" library names and
allowing the user to choose between
static/shared,thread/non-thread,debug/release builds.
Andreas
--
You will be married within a
On 20.01.08 15:38:44, Rodolfo Lima wrote:
> Andreas Pakulat escreveu:
> > The reason I did that was to simplify the module code.
>
> I see, but this variable is only used in a if clause, so instead of writing
>
> IF( Boost_USE_NONMULTITHREADED )
> SET (_boost_M
On 20.01.08 19:15:33, Andreas Schneider wrote:
> Rodolfo Lima wrote:
> > Again, it would be good if we could choose which version to detect. If I
> > have 1.33.0 and 1.34.1, I want my application to use 1.34.1 and beyond.
>
> You can simply overwrite the variable _boost
33boost-1_33
> )
>
> This way it finds the latest available boost version, and allows the
> user to specify a different one simply by selecting a different dir
> for the boost_include_dir.
You can already specify the version you want to use. Simply overwrite
_boost_TEST_VE
On 20.01.08 17:11:17, Rodolfo Lima wrote:
> Andreas Pakulat escreveu:
>
> > Naah, _boost_XXX is internal and not exposed. I rather have a
> > Boost_MINIMUM_VERSION. That would also allow to use REQUIRED and a more
> > verbose message saying wether the version is wrong or
On 20.01.08 19:45:03, Hendrik Sattler wrote:
> Am Sonntag 20 Januar 2008 schrieb Andreas Pakulat:
> > On 20.01.08 15:38:44, Rodolfo Lima wrote:
> > > Andreas Pakulat escreveu:
> > > > The reason I did that was to simplify the module code.
> > >
> > &g
On 20.01.08 16:05:02, Miguel A. Figueroa-Villanueva wrote:
> On Jan 20, 2008 2:17 PM, Andreas Pakulat wrote:
> > On 20.01.08 14:02:32, Miguel A. Figueroa-Villanueva wrote:
> > The real problem is actually building up the "right" library names and
> > allowing the us
On 21.01.08 08:53:58, Brad King wrote:
> Andreas Pakulat wrote:
> > On 20.01.08 17:11:17, Rodolfo Lima wrote:
> >> Andreas Pakulat escreveu:
> >>
> >>> Naah, _boost_XXX is internal and not exposed. I rather have a
> >>> Boost_MINIMUM_VERSIO
e unreadable.
Also it relies on the autoconf macro's to be written in a way that they
output the information needed. The same thing is true for CMake
buildsystems, if the author didn't care to create proper messages when
it doesn't find an optional dependecy then you should blame that
error out on the second line, while cmake 2.4.7
works fine. Is that a bug in 2.4.5 which got fixed in 2.4.7?
The error is:
CMake Error: Error in cmake code at
/home/andreas/KDE-work/4.0/kdevplatform/cmake/modules/FindBoost.cmake:267:
IF had incorrect arguments: Boost_VERSION LESS
On 24.01.08 14:59:19, Brandon Van Every wrote:
> On Jan 24, 2008 2:50 PM, Andreas Pakulat <[EMAIL PROTECTED]> wrote:
> >
> > Any ideas how to solve this (besides upgrading cmake)?
>
> Quotes?
Thanks.
Andreas
--
Don't get to bragging.
_
On 20.01.08 00:09:40, Andreas Pakulat wrote:
> Hi,
>
> apparently the FindBoost.cmake I attached to
> http://www.cmake.org/Bug/view.php?id=6257
>
> isn't quite perfect - actually not even close. The last few days I've
> worked with Andreas Schneider to make i
501 - 600 of 1033 matches
Mail list logo
