On Wednesday 04 August 2010 08:30:49 Dennis Schridde wrote:
> Hi!
>
> We
have a problem in our cmake project, where cmake links all libraries
> two
times. This makes it impossible to link static libraries.
> The libraries
>
appear only once in target_link_libraries() and that also only appears
>
o
Hi! Please provide a build log with VERBOSE=1 and a sample CMakeLists.txt,
where you have a problem. Denis
> We have a problem in our cmake project, where cmake links all libraries
> two times. This makes it impossible to link static libraries.
> The libraries
> appear only once in target_link_li
Hi!
We have a problem in our cmake project, where cmake links all libraries
two times. This makes it impossible to link static libraries.
The libraries
appear only once in target_link_libraries() and that also only appears
once.
Has someone idea what we could be doing wrong?
Thank you,
Dennis
On Monday 02 Aug 2010 4:59:47 pm Eric Noulard wrote:
> Hi All,
>
> I did add a patch for the "multiple file problem"
> http://public.kitware.com/Bug/view.php?id=10736
>
> May be interested people can have a try and comment
> this patch.
>
> It adds the possibility for any CPack generators to ge
On Wednesday 04 Aug 2010 1:49:36 am Clinton Stimpson wrote:
> On Tuesday, August 03, 2010 02:07:31 pm Alexander Neundorf wrote:
> > On Saturday 31 July 2010, Clinton Stimpson wrote:
> > > If you put main.moc in add_executable() then you don't have to use the
> > > set_source_files_properties() to m
2010/8/2 Eric Noulard :
> Hi All,
>
> I did add a patch for the "multiple file problem"
> http://public.kitware.com/Bug/view.php?id=10736
>
> May be interested people can have a try and comment
> this patch.
>
> It adds the possibility for any CPack generators to generate multiple file.
> It adds
You just need to build Qt as static libraries with the configure -static
option.
There's nothing else you need to change in your CMake setup, so you can keep
your BUILD_SHARED_LIBS flag as you want and Qt is not affected by it.
Clint
On Tuesday, August 03, 2010 04:40:50 pm Glenn Hughes wrote:
Hey,
I'd like to hard-link Qt in my application, while at the same time
allowing some of my other libraries to build as DLLs. Last time I
looked cmake just had a single 'either or' option for building either
as shared libraries or without. Is there some way to do a mixed build
like this, and more
On 2010-08-03 07:57-0400 David Cole wrote:
When there are multiple matching installations, the developer must specify
which one he wants. The way he does that varies from module to module, but
it is always do-able by simply setting some cache values to point to the
right stuff.
I agree about
On Tuesday, August 03, 2010 02:07:31 pm Alexander Neundorf wrote:
> On Saturday 31 July 2010, Clinton Stimpson wrote:
> > If you put main.moc in add_executable() then you don't have to use the
> > set_source_files_properties() to manually specify dependencies.
>
> Yes, but main.moc is already #inc
2010/8/3 Eric Noulard :
> 2010/8/3 David Cole :
>> On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard wrote:
>
>>>
>>> 2. may always be an option because it was the behavior we had before the
>>> component support and ALL CPack generator may handle an all-in-one
>>> package.
>>> We could add an OPTION l
On Saturday 31 July 2010, Clinton Stimpson wrote:
> If you put main.moc in add_executable() then you don't have to use the
> set_source_files_properties() to manually specify dependencies.
Yes, but main.moc is already #included in main.cpp so it cannout be added to
add_executable.
In KDE we are
2010/8/3 Eric Noulard :
> 2010/8/3 Dr. Stefan Sablatnög :
>> Hi all,
>>
>> first of all many thanks for considering to provide such a functionality.
>> I tried it on an small example yesterday and it worked as expected
>> (I patched against cmake 2.8.2), a larger test will follow as soon as I
>> fi
I'm working on replacing an antiquated custom build system with cmake on
a project which uses a mix of several flavors of Fortran as well as some
C and C++. The problem I'm running into is that FIND_MPI (and I would
guess a variety of other modules) just assume that the compiler flags
should be the
2010/8/3 David Cole :
> On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard wrote:
>>
>> 2. may always be an option because it was the behavior we had before the
>> component support and ALL CPack generator may handle an all-in-one
>> package.
>> We could add an OPTION like CPACK_COMPONENT_ALL_IN_ONE wh
2010/8/3 Dr. Stefan Sablatnög :
> Hi all,
>
> first of all many thanks for considering to provide such a functionality.
> I tried it on an small example yesterday and it worked as expected
> (I patched against cmake 2.8.2), a larger test will follow as soon as I
> find the time.
Ok thanks.
Do not
On Tue, Aug 3, 2010 at 8:01 AM, Michael Wild wrote:
> ;-) Thanks David.
>
> One thing remains which also sucks and I don't know enough about: Windows.
> I know that many software packages create registry entries naming the
> installation directory etc. Hopefully they do that for each installed
>
;-) Thanks David.
One thing remains which also sucks and I don't know enough about: Windows. I
know that many software packages create registry entries naming the
installation directory etc. Hopefully they do that for each installed version
individually, but do they also create a "latest-versio
Bingo.
With more than one of *anything* installed, the find modules can only guess.
They can never know which one is correct.
In the presence of exactly one installation of something, the find modules
are wonderful.
In the presense of two or more, the find modules suck eggs for half the
users (o
On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard wrote:
> 2010/8/2 Clinton Stimpson :
> >>
> >> Waiting for feedback before going on
> >
> > So I wondered if we were basically getting 3 modes out of this:
> >
> > 1. put multiple components in one components aware package (nsis,
> packagemaker,...).
>
Hi Michael,
> Do you want stripping during build time? That's unusual... Only way I see to
> do it is to wrap add_executable and add_library in a custom function and add
> a POST_BUILD custom command and invoke the CMAKE_STRIP tool manually. Only
> problem I see is to find the output location o
On 3. Aug, 2010, at 9:26 , Martin Wodok wrote:
> Thanks D3ck0r,
>
>> Personally I'd add
>>
>> set(CMAKE_BUILD_TYPE "Debug" CACHE STRING
>> "Set build type")
>> set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
>> "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
>>
>> to
How about ditching the whole idea of finding the latest version and just search
for un-versioned names? If the user wants something different, she should set
PYTHON_EXECUTABLE.
Michael
On 3. Aug, 2010, at 7:37 , Michael Hertling wrote:
> On 07/22/2010 02:17 PM, Marcel Loose wrote:
>> Hi all,
Thanks D3ck0r,
> Personally I'd add
>
> set(CMAKE_BUILD_TYPE "Debug" CACHE STRING
> "Set build type")
> set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
>"Debug" "Release" "MinSizeRel" "RelWithDebInfo")
>
> to my root project, and select option release default... or
Thanks Alex,
> > I'm new to CMake, but have of course already searched for a solution on
> > the web. I often found the info that CMake doesn't strip the binaries,
> > but no solution to that.
> > So is there a way to get the Release (and not the debug) build to
> > produce a stripped binary (unde
Hi all,
first of all many thanks for considering to provide such a functionality.
I tried it on an small example yesterday and it worked as expected
(I patched against cmake 2.8.2), a larger test will follow as soon as I
find the time.
One minor thing (maybe a different issue?),
I am not quite s
26 matches
Mail list logo
