Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher schrieb:
during your new warning when mixing libs in target_link_libraries
(CMP0003) I changed target_link_libraries(foo ws2_32) to
find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})
but now cmake finds ws2_32.dll in system32 instead the correct one
(ws2_32.dll.a / ws2_32.a) in mingw dir.
Set the LIB environment variable to the MinGW lib dir. While you are at
it, do the same for INCLUDE.
This is comparable to the setup for cl.
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
> Von: Hendrik Sattler
> Christian Ehrlicher schrieb:
> > during your new warning when mixing libs in target_link_libraries
> > (CMP0003) I changed target_link_libraries(foo ws2_32) to
> >
> > find_library(WS2_32_LIBRARY ws2_32)
> > target_link_libraries(foo ${WS2_32_LIBRARY})
> >
> > but now cmake finds ws2_32.dll in system32 instead the correct one
> > (ws2_32.dll.a / ws2_32.a) in mingw dir.
> Set the LIB environment variable to the MinGW lib dir. While you are at
> it, do the same for INCLUDE.
> This is comparable to the setup for cl.
>
Also they solution is clear I don't like it. MinGW doesn't care about LIB
(otherwise it wouldn't link against ws2_32.a) so why should cmake do in this
case?
The problem is the new warning - it suggest that a simple find_library would do
the job but it doesn't - it breaks compilation. Looks like this warning is the
first one which I'll disable by default. Maybe also in kde4/win because it's
imho useless when linking against system libs (on windows).
Christian
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher schrieb:
Von: Hendrik Sattler
Christian Ehrlicher schrieb:
during your new warning when mixing libs in target_link_libraries
(CMP0003) I changed target_link_libraries(foo ws2_32) to
find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})
but now cmake finds ws2_32.dll in system32 instead the correct one
(ws2_32.dll.a / ws2_32.a) in mingw dir.
Set the LIB environment variable to the MinGW lib dir. While you are at
it, do the same for INCLUDE.
This is comparable to the setup for cl.
Also they solution is clear I don't like it. MinGW doesn't care about LIB
(otherwise it wouldn't link against ws2_32.a) so why should cmake do in this
case?
The problem is the new warning - it suggest that a simple find_library would do
the job but it doesn't - it breaks compilation. Looks like this warning is the
first one which I'll disable by default. Maybe also in kde4/win because it's
imho useless when linking against system libs (on windows).
Did find_library in CMake 2.4 find he correct one?
I also think that this could be improved: for "MinGW Makefiles"
generator, cmake could get the base MinGW directory and add
the lib/ and include/ subdirs to the front of default paths. Then,
find_library() would magically work again.
Do you want to create a bug tracker entry for that issue?
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
> Von: Hendrik Sattler
> Christian Ehrlicher schrieb:
> >> Von: Hendrik Sattler
> >> Christian Ehrlicher schrieb:
> >>
> >>> during your new warning when mixing libs in target_link_libraries
> >>> (CMP0003) I changed target_link_libraries(foo ws2_32) to
> >>>
> >>> find_library(WS2_32_LIBRARY ws2_32)
> >>> target_link_libraries(foo ${WS2_32_LIBRARY})
> >>>
> >>> but now cmake finds ws2_32.dll in system32 instead the correct one
> >>> (ws2_32.dll.a / ws2_32.a) in mingw dir.
> >>>
> >> Set the LIB environment variable to the MinGW lib dir. While you are at
> >> it, do the same for INCLUDE.
> >> This is comparable to the setup for cl.
> >>
> >>
> > Also they solution is clear I don't like it. MinGW doesn't care about
> LIB (otherwise it wouldn't link against ws2_32.a) so why should cmake do in
> this case?
> > The problem is the new warning - it suggest that a simple find_library
> would do the job but it doesn't - it breaks compilation. Looks like this
> warning is the first one which I'll disable by default. Maybe also in kde4/win
> because it's imho useless when linking against system libs (on windows).
> >
> Did find_library in CMake 2.4 find he correct one?
Don't know but don't think so - I completly switched to 2.6 a while ago.
> I also think that this could be improved: for "MinGW Makefiles"
> generator, cmake could get the base MinGW directory and add
> the lib/ and include/ subdirs to the front of default paths. Then,
> find_library() would magically work again.
> Do you want to create a bug tracker entry for that issue?
I will - just wanted to discuss it here to see if you maybe can convince me
that's the correct behaviour for mingw :)
Christian
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher wrote:
Hi,
during your new warning when mixing libs in target_link_libraries
(CMP0003) I changed target_link_libraries(foo ws2_32) to
find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})
but now cmake finds ws2_32.dll in system32 instead the correct one
(ws2_32.dll.a / ws2_32.a) in mingw dir.
A!!!
This is the most misunderstood warning of all times :)
You do not have to use full paths for all libraries now.
You do not have to use full paths for all libraries now.
For system libraries like this one it is much safer to just list them.
If you set the policy to NEW, it will just work with no warnings. The
warning says that it maybe a problem, but to try it as NEW, and if it is
not a problem, then you are good.
For this case I would recommend changing ws2_32 to not being found. It
is a standard library that the compiler should be able to find the
appropriate version of.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
> Von: Bill Hoffman
> Christian Ehrlicher wrote:
> > Hi,
> >
> > during your new warning when mixing libs in target_link_libraries
> > (CMP0003) I changed target_link_libraries(foo ws2_32) to
> >
> > find_library(WS2_32_LIBRARY ws2_32)
> > target_link_libraries(foo ${WS2_32_LIBRARY})
> >
> > but now cmake finds ws2_32.dll in system32 instead the correct one
> > (ws2_32.dll.a / ws2_32.a) in mingw dir.
> >
>
>
> A!!!
>
> This is the most misunderstood warning of all times :)
>
>
> You do not have to use full paths for all libraries now.
> You do not have to use full paths for all libraries now.
>
> For system libraries like this one it is much safer to just list them.
> If you set the policy to NEW, it will just work with no warnings. The
> warning says that it maybe a problem, but to try it as NEW, and if it is
> not a problem, then you are good.
>
> For this case I would recommend changing ws2_32 to not being found. It
> is a standard library that the compiler should be able to find the
> appropriate version of.
>
I understood the warning - I know that it is not mandatory. But how useful is a
warning when the only way to get rid of them is to disable it? I either have to
fix all places (including the system libs) or disable it and don't care at all.
That's stupid.
Christian
--
Desperate Housewives - das Spiel!
Pikante Skandale, schockierende Details unter: http://flat.games.gmx.de
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher wrote: > I understood the warning - I know that it is not mandatory. But how useful is > a warning when the only way to get rid of them is to disable it? I either > have to fix all places (including the system libs) or disable it and don't > care at all. That's stupid. Adding the code the warning suggests does *not* disable it. It is actually a *fix* for the condition that produces the warning. CMake is telling you that it is enabling some old (bad) behavior for compatibility because it has not been told that it is safe to use the new behavior and is unable to detect whether it is safe. The suggested code cmake_policy(SET CMP0003 NEW) tells CMake to use the new behavior...it will actually produce a *different link line* for the target. If the project was not depending on the old behavior it will just work. However, if the project was depending on the old behavior it will not link and then the offending code will have to be fixed (add a link directory or use a full path for the lib that cannot be found). In that case the author that is adding the line above can update the code too. The key to the policy design is that in either case joe user doesn't have to do anything to get the project to build without modification. Another way to tell CMake to use the new behavior is to require CMake 2.6 (which will get rid of this problem completely in the future): cmake_minimum_required(VERSION 2.6) This is all explained by documentation: http://www.cmake.org/Wiki/CMake_Policies http://www.cmake.org/HTML/cmake-2.6.html#policy:CMP0003 http://www.cmake.org/Wiki/CMake_2.6_Notes#Missing_Linker_Search_Directories cmake --help-policy CMP0003 cmake --help-command cmake_policy cmake --help-command cmake_minimum_required -Brad BTW, the code cmake_policy(SET CMP0003 OLD) # note OLD, not NEW or the command line option -Wno-dev would be disabling the warning without changing behavior. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher wrote: I understood the warning - I know that it is not mandatory. > But how useful is a warning when the only way to get rid of them is > to disable it? I either have to fix all places (including the system libs >) or disable it and don't care at all. That's stupid. OK, so you don't understand the warning. Not your fault it is just hard to write as many others do not understand it. Here is the problem: We changed from -L/path/to -lA to /path/to/library. In some rare cases projects have something like this: target_link_libraries(foo /path/to/libA.a B) And B is actually in /path/to/libB.a We have no easy way of telling the difference between the above and target_link_libraries(foo /path/to/libA.a somesystemlib) Where somesystemlib library can be found by the compiler. So, we had two choices for 2.6: 1. Always add -L/path if there is at least one non-full path library linked in. This makes extra long link lines. 2. Do not add -L/path and give no warning - we will break some projects with no warning, and the break will happen with a linker error during the build step. So, what we did was do 1 by default, but give a warning. So, to make a long story short, setting the policy to NEW is not "disabling" the warning, it is asking CMake to link libraries in the new better 2.6 way. So, the correct fix is to set the policy to NEW, and if your stuff links then the warning was in error. If a project has 2.6 as the minimum require version there is no warning and things are always linked full path. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Bill Hoffman schrieb: Christian Ehrlicher wrote: I understood the warning - I know that it is not mandatory. > But how useful is a warning when the only way to get rid of them is > to disable it? I either have to fix all places (including the system libs >) or disable it and don't care at all. That's stupid. OK, so you don't understand the warning. Not your fault it is just hard to write as many others do not understand it. Here is the problem: We changed from -L/path/to -lA to /path/to/library. In some rare cases projects have something like this: target_link_libraries(foo /path/to/libA.a B) And B is actually in /path/to/libB.a We have no easy way of telling the difference between the above and target_link_libraries(foo /path/to/libA.a somesystemlib) Where somesystemlib library can be found by the compiler. So, we had two choices for 2.6: 1. Always add -L/path if there is at least one non-full path library linked in. This makes extra long link lines. 2. Do not add -L/path and give no warning - we will break some projects with no warning, and the break will happen with a linker error during the build step. So, what we did was do 1 by default, but give a warning. So, to make a long story short, setting the policy to NEW is not "disabling" the warning, it is asking CMake to link libraries in the new better 2.6 way. So, the correct fix is to set the policy to NEW, and if your stuff links then the warning was in error. If a project has 2.6 as the minimum require version there is no warning and things are always linked full path. Thx for the explanation. Christian signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher wrote: Thx for the explanation. No problem, how do you think we could reword the warning to avoid future confusion? You are certainly not alone here. :) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
