--snip--
I'm using Boost and I've never hard to work with special defines and
compile flags. That's the power of proper automatic support.
--end snip--
That's the power of Boost. These guys have really figured it out. I too
would like to see some of the Boost.Build concepts make their way into
C
On Fri, Jul 23, 2010 at 12:23 AM, Michael Jackson
wrote:
>> Tweaked in what way?
>
> Usually they have special CMake variables for the specific project that the
> original sources were being built as part of. These all have to be cleaned
> up. Then sometimes you would like to add some of your own
On Jul 22, 2010, at 6:17 PM, Olaf van der Spek wrote:
On Fri, Jul 23, 2010 at 12:00 AM, Michael Jackson
wrote:
Yes, it was done already (For some of them) which is what I started
with.
But what you find is that the CMake files that someone wrote are
kinda
"tweaked" for their project and do
On Fri, Jul 23, 2010 at 12:00 AM, Michael Jackson
wrote:
> Yes, it was done already (For some of them) which is what I started with.
> But what you find is that the CMake files that someone wrote are kinda
> "tweaked" for their project and don't really work for yours so you end up
Tweaked in what
> I'm on the other side of that one. I don't know how many _days_ I have
> wasted because I linked my debug version with a release version of something
> else and had the strangest errors and app crashes. After pulling my hair out
> trying to debug something that does not need to be debugged I fina
On Jul 22, 2010, at 5:53 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 11:50 PM, Michael Jackson
wrote:
Of course I have separate projects. I didn't write libz... Did you?
DLLs should be *shared*. There shouldn't be a need for me to copy
them
to my app dir.
Well,
Actually I _di
On Jul 22, 2010, at 5:40 PM, J Decker wrote:
On Thu, Jul 22, 2010 at 2:37 PM, John Drescher
wrote:
On Thu, Jul 22, 2010 at 5:25 PM, J Decker wrote:
I'll add my two cents - I like that the names are the same, it
allows
me to switch the release out with the debug and not have to
recompil
On Thu, Jul 22, 2010 at 11:50 PM, Michael Jackson
wrote:
>> Of course I have separate projects. I didn't write libz... Did you?
>> DLLs should be *shared*. There shouldn't be a need for me to copy them
>> to my app dir.
>
> Well,
> Actually I _did_ put a CMake wrapper on LibZ that _does_ in fact
On Jul 22, 2010, at 5:42 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 11:36 PM, Michael Jackson
wrote:
How does the loader find the DLL?
Because when Visual Studio launches an executable it will look in
the same
directory that the executable resides in for libraries to load.
Now
On Thu, Jul 22, 2010 at 2:37 PM, John Drescher wrote:
> On Thu, Jul 22, 2010 at 5:25 PM, J Decker wrote:
>> I'll add my two cents - I like that the names are the same, it allows
>> me to switch the release out with the debug and not have to recompile
>> the executable.
>
>
> You are not supposed
On Thu, Jul 22, 2010 at 11:36 PM, Michael Jackson
wrote:
>> How does the loader find the DLL?
>
> Because when Visual Studio launches an executable it will look in the same
> directory that the executable resides in for libraries to load. Now, if you
> have 2 completely separate projects where one
On Jul 22, 2010, at 5:25 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 11:14 PM, Michael Jackson
wrote:
So here is what really happens with Visual Studio. When you
invoke CMake
you select to build "Shared" libraries and a Win64 application.
These are
the basics. Visual Studio wi
> You _can_ very easily do this if you want. The code is out there in the
> wild in the form of macros that can be invoked from CMake that will set all
> of this up for you. You just have to look for it (or ask the right person...
> )
>
I do this for my shared libraries although I do not put the
I'll add my two cents - I like that the names are the same, it allows
me to switch the release out with the debug and not have to recompile
the executable. Besides, I doubt your interface changes because of
debug or release mode - so the .lib should be exactly the same.
Though I suppose if you pas
On Thu, Jul 22, 2010 at 11:14 PM, Michael Jackson
wrote:
> So here is what really happens with Visual Studio. When you invoke CMake
> you select to build "Shared" libraries and a Win64 application. These are
> the basics. Visual Studio will create a subdirectory for "Debug" and
> "Release" vari
On Jul 22, 2010, at 4:54 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 10:46 PM, Michael Jackson
wrote:
Ya know , I go back and forth on this. In my own projects I will
give my
libs a _debug suffix because I end up installing both debug and
release into
a local directory and my Find
On Thu, Jul 22, 2010 at 10:46 PM, Michael Jackson
wrote:
> Ya know , I go back and forth on this. In my own projects I will give my
> libs a _debug suffix because I end up installing both debug and release into
> a local directory and my FindXXX.cmake scripts know to look for both a debug
> and re
On Thu, Jul 22, 2010 at 10:46 PM, John Drescher wrote:
> On Thu, Jul 22, 2010 at 4:43 PM, Olaf van der Spek
> wrote:
>> On Thu, Jul 22, 2010 at 10:41 PM, John Drescher wrote:
And then what? Having two DLLs with the same name is not going to
work. Same for import or static libs.
>>>
>>
On Jul 22, 2010, at 4:38 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 10:32 PM, Ryan Pavlik
wrote:
Unfortunately there are as many ways to denote these differences as
there
are projects. However, unless you're setting the
ARCHIVE_OUTPUT_DIRECTORY,
LIBRARY_OUTPUT_DIRECTORY, or RUNTI
On Thu, Jul 22, 2010 at 4:43 PM, Olaf van der Spek wrote:
> On Thu, Jul 22, 2010 at 10:41 PM, John Drescher wrote:
>>> And then what? Having two DLLs with the same name is not going to
>>> work. Same for import or static libs.
>>
>> It would work fine if the dlls for multiple configurations were
On Thu, Jul 22, 2010 at 10:41 PM, John Drescher wrote:
>> And then what? Having two DLLs with the same name is not going to
>> work. Same for import or static libs.
>
> It would work fine if the dlls for multiple configurations were not
> all dumped in 1 folder. That is how I have used cmake for 2
> And then what? Having two DLLs with the same name is not going to
> work. Same for import or static libs.
It would work fine if the dlls for multiple configurations were not
all dumped in 1 folder. That is how I have used cmake for 2+ years.
John
___
On Thu, Jul 22, 2010 at 10:32 PM, Ryan Pavlik wrote:
> Unfortunately there are as many ways to denote these differences as there
> are projects. However, unless you're setting the ARCHIVE_OUTPUT_DIRECTORY,
> LIBRARY_OUTPUT_DIRECTORY, or RUNTIME_OUTPUT_DIRECTORY (and if you are, I
> highly suggest
On Thu, Jul 22, 2010 at 10:32 PM, John Drescher wrote:
>> Shouldn't this be done automatically?
>
> No way. Not all users would want that on all platforms that CMake
> supports.
Who is talking about all platforms?
> Also it is very easy to add a single line to your
> CMakeLists.txt file..
So?
> Shouldn't this be done automatically?
No way. Not all users would want that on all platforms that CMake
supports. Also it is very easy to add a single line to your
CMakeLists.txt file..
> What about shared vs static lib?
> Shared vs static runtime?
> x64 vs x86?
You can do all of that similarl
On 7/22/2010 3:23 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 9:23 PM, Ryan Pavlik wrote:
On 7/22/10 10:08 AM, Olaf van der Spek wrote:
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only got a single
lib dir.
On Thu, Jul 22, 2010 at 9:23 PM, Ryan Pavlik wrote:
> On 7/22/10 10:08 AM, Olaf van der Spek wrote:
>>
>> Hi,
>>
>> All target names have the same base name. So both the debug and
>> release variant are called xbt.lib. However, I've only got a single
>> lib dir. Shouldn't all variants have a uniq
On 7/22/10 10:08 AM, Olaf van der Spek wrote:
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only got a single
lib dir. Shouldn't all variants have a unique name?
Olaf
set(CMAKE_DEBUG_POSTFIX _d)
See the documentation for
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only got a single
lib dir. Shouldn't all variants have a unique name?
Olaf
___
Powered by www.kitware.com
Visit other Kitware open-sou
29 matches
Mail list logo
