Re: [CMake] Cmake issue compiling CLucene
On 1/7/2013 3:18 PM, Hatchi wrote: Hello Mike I also tried from the VS command prompt but it gives the same problem with the linker it seems... Does this work for you: http://stackoverflow.com/questions/12267158/failure-during-conversion-to-coff-file-invalid-or-corrupt -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake issue compiling CLucene
Hello Mike I also tried from the VS command prompt but it gives the same problem with the linker it seems... -- View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-issue-compiling-CLucene-tp7582775p7582803.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja and *.i targets
Óscar Fuentes wrote: > Stephen Kelly writes: > >> While at it, you comb this thread to see if there are other feature >> requests there which are not in the bug tracker: >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475 > > Good idea. > > Apart from the .i targets, the only non-controversial unimplemented > feature I see is the generation of .s targets. Created a feature request > here: > > http://public.kitware.com/Bug/view.php?id=13839 > Great, thanks! -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja and *.i targets
Stephen Kelly writes: > While at it, you comb this thread to see if there are other feature requests > there which are not in the bug tracker: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475 Good idea. Apart from the .i targets, the only non-controversial unimplemented feature I see is the generation of .s targets. Created a feature request here: http://public.kitware.com/Bug/view.php?id=13839 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] install(EXPORT ...) behavior for multi-configuration generators
Hello,
I am using CMake 2.8.10.2, on windows.
I am trying to use install(TARGETS ) and install(EXPORT ) both with NMake
makefiles and with the multi-configuration generator Visual studio.
I cannot get the same behavior when I want my binaries to be installed in a
subfolder that depends on the configuration, e.g. :
- Debug/bin/myLib.dll
- Release/bin/myLib.dll
If I do that :
#start
install(TARGETS "myLib" EXPORT " myTargets "
ARCHIVE DESTINATION "\${CMAKE_INSTALL_CONFIG_NAME}/lib"
LIBRARY DESTINATION"\${CMAKE_INSTALL_CONFIG_NAME}/lib"
RUNTIME DESTINATION "\${CMAKE_INSTALL_CONFIG_NAME}/bin"
)
install(EXPORT "myTargets" DESTINATION "cmake")
#end
This works find for NMake and Visual for install rules because
${CMAKE_INSTALL_CONFIG_NAME} will be evaluated at install time.
But in my myTargets-debug.cmake import files, ${CMAKE_INSTALL_CONFIG_NAME} will
not be evaluated correctly.
Now If I do that:
#start
install(TARGETS "myLib" EXPORT " myTargets "
ARCHIVE DESTINATION "Debug/lib"
LIBRARY DESTINATION"Debug/lib"
RUNTIME DESTINATION "Debug/bin"
CONFIGURATIONS Debug
)
install(TARGETS "myLib" EXPORT " myTargets "
ARCHIVE DESTINATION "Release/lib"
LIBRARY DESTINATION"Release/lib"
RUNTIME DESTINATION "Release/bin"
CONFIGURATIONS Release
)
install(EXPORT "myTargets" DESTINATION "cmake")
# end
CMake will complain that:
CMake Error: INSTALL(EXPORT " myTargets " ...) includes target " myLib " more
than once in the export set.
Is this a bug that CMake complains about a target being exported twice but with
different configurations?
Does anyone have a workaround?
Regards,
Gregoire
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja and *.i targets
Bill Hoffman writes: > On 1/5/2013 3:49 PM, Óscar Fuentes wrote: >> With the `Unix Makefiles' generator, a foo.i target is generated for >> foo.cpp. That's very convenient. However, ninja doesn't list such >> targets under `ninja help' and `ninja foo.i' complains about unknown >> target. > > This is a missing feature. Can you create a feature request for it in > the bug tracker? Done: http://public.kitware.com/Bug/view.php?id=13838 Thanks. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja and *.i targets
Bill Hoffman wrote: > On 1/5/2013 3:49 PM, Óscar Fuentes wrote: >> With the `Unix Makefiles' generator, a foo.i target is generated for >> foo.cpp. That's very convenient. However, ninja doesn't list such >> targets under `ninja help' and `ninja foo.i' complains about unknown >> target. >> >> Is this feature missing from the ninja generator? Is it because is hard >> to implement or just lack of time? >> >> I'm using cmake 2.8.9 and ninja 1.0.0 on Linux. > This is a missing feature. Can you create a feature request for it in > the bug tracker? While at it, you comb this thread to see if there are other feature requests there which are not in the bug tracker: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475 Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja and *.i targets
On 1/5/2013 3:49 PM, Óscar Fuentes wrote: With the `Unix Makefiles' generator, a foo.i target is generated for foo.cpp. That's very convenient. However, ninja doesn't list such targets under `ninja help' and `ninja foo.i' complains about unknown target. Is this feature missing from the ninja generator? Is it because is hard to implement or just lack of time? I'm using cmake 2.8.9 and ninja 1.0.0 on Linux. This is a missing feature. Can you create a feature request for it in the bug tracker? Thanks. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Selective build and install of subfolders
writes: > > Hello list, > > I have a project with subfolders that should be selectively > built and installed. > The problem is that there are various dependencies between them. > [snip] Hi Stefan, I think you should look into options, and the CMake dependent option macro. http://www.cmake.org/cmake/help/v2.8.4/cmake.html#command:option http://www.cmake.org/cmake/help/v2.8.4/cmake.html#module:CMakeDependentOption The idea is to guard add_subdirectory commands with if commands. The if commands would be checking the value of the options. It's not really pretty, but it may be enough for you to do the job. Hope that it helps. -- Amine -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What is the proper cross-platform way to link the Python library?
Alan W. Irwin wrote: > If/when that python.org bug is fixed I will look into the Is it reported? If not it won't get fixed. I assume you saw this? http://thread.gmane.org/gmane.comp.science.paraview.user/10956/focus=11019 I wonder if that David reported it either. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Tracker.exe response file error
Hi all. On Windows, Visual Studio 2010, some machines in our company experience this error ( http://connect.microsoft.com/VisualStudio/feedback/details/540902/tracker-exe-response-file-not-found) when "detecting C compiler", which makes it impossible to use CMake on them. The workaround (mentioned in the link) would be to add the following to the .vcxproj generated for try_compile: false Or add the following to the msbuild command line: /p:TrackFileAccess=false Is there a way to do this with the current capabilities of CMake (any of env.var, cache var, command-line option, ...)? Or should I raise a bug report? Has anyone encountered this problem, and is there a solution? Thanks in advance. Petr -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake absolute paths with gcc, __FILE__ , and logging
really sorry, last mail was sent too early X-(
2013/1/7 Willy Lambert :
> 2013/1/4 Andreas Mohr :
>> Hi,
>>
>> On Fri, Jan 04, 2013 at 11:47:40AM -0500, cmake-requ...@cmake.org wrote:
>>> Date: Fri, 4 Jan 2013 16:58:05 +0100
>>> From: Willy Lambert
>>
>>> Hi all,
>>>
>>> Short Story :
>>>
>>> I am trying to convert an existing project from Manual Makefiles to
>>> Cmake for building it.
>>> We have a logger that rely on the __FILE__ define to say which file is
>>> "writing" into the log but this is broken by the CMake default
>>> behavior using absolute paths.
>>> So I wonder if there is any way to have the file name in the code to
>>> be able to log "Error : line XXX in file.cpp".
>>>
>>>
>>>
>>>
>>> Long Story :
>>>
>>>
>>>
>>> So I have for instance a source /home/me/src/main.cpp, compiled with
>>> relative paths "gcc -o main.cpp".
>>> So the logger say "Error : line XXX in main.cpp".
>>
>> I'm afraid given the discussion at
>> "Short form of __FILE__"
>> http://bytes.com/topic/c/answers/453661-short-form-__file__
>>
>> the onus is on your project since it seems to be relying on
>> seemingly rather volatile (non-standardized) behaviour of the __FILE__ macro
>> (compilers seem to be free to pass on either a file's basename only
>> or a relative path or even a FQPN).
>
> Depends what you listen under standard. In my case it's standrd with
> GNU tools. If you know how I could log filename + line number in a
> standardized way let me know (or point links), I'll be very happy for
> that. For now, I'm only expected my project working with GNU, and only
> it (which is rather by necessity than by choice).
>
>> And now that one is using a CMake build which needs to do builds from
>> an entirely separate binary tree referencing source files in a
>> foreign source tree (thus having a justified reason for needing to
>> specify paths in full),
>
> Yes and no. Yes, CMake has to manage a "source root dir" and a "binary
> output dir" (and maybe a relative path from source to build ?), but
> I'm not sure that you *need* it to build (see the
> CMAKE_USE_RELATIVE_PATHS option that is already working on simple
> cases). In my case, it's a "classical" CMake tructure :
> myproject/
build
src
so I understand that cmake has to know about internal src/build
structure (and I wouldn't mind cmake using src/XXX path without being
able to prevent the src particule which is not a problem). What I
don't want is having information in my binaries about my "myproject"
folder location.
>
>
> So it's a strong reason in current implementation, not sure it is
> justified. Nevertheless I'm aware that as all free project it has
> limitation, lack of contributions, etc, ... what I mean is that I'm
> not sure that the onus of this is *only* my project.
>
> I have 3 solutions (in this order of priority) :
> _ extending Cmake
> _ finding a hack
> _ changing log system (for an obvious reason you can't switch easily
> an existing project regarding log because there are lot of work to do)
>
>
>> these improper assumptions in your project
>> seem to fall flat on their face, since gcc chooses to prefer to pass on
>> as much information to the __FILE__ macro as it can get
>> about the file location (i.e., full path).
>
> It's not really improper since I choosed GNU gcc, so everything is
> behaving as expected. What is not behaving as expected (on my point of
> view, with is relative), the improper assumption is that Cmake doesn't
> hide
the path to the project
>
>>
>> Since the problem is thus firmly located on the source code side
>> (i.e. its assumptions about __FILE__),
>> I'd suggest treating the problem right there,
>> using e.g. the discussion's strrchr() solution
>> ("workaround"?) to achieve a slightly improved guarantee of gaining
>> sufficiently constant output format (but note that Keith Thompson noted
>> that the C language itself does not have any business dealing with path
>> separator definitions).
Thanks for pointing this link, very interesting.
The strrchr() solution is demanding computation at run time, which is
quite a pity (not to see a problem as it is an embedded project).
But at least it's a solution.
>>
>>
>>> I tried to use the suggested trigger "set_source_files_properties" to
>>> define my own __FILE__ but it doesn't works with included files (it
>>> shows main.cpp instead oh dummy.hpp)
>>> http://www.cmake.org/pipermail/cmake/2011-December/048281.html
>>>
>>> So this way is a dead end because the compilator (and the one that
>>> creates its command line) is the only one to be aware of this
>>> information.
>>>
>>> Beside that, as I would really like to simplify the "VERBOSE=2 make"
>>> output to be able to debug what CMake generates I currently have
>>> plenty of path with 20 or more folder level including many "../..", I
>>> am looking on making CMake giving relatives paths to gcc.
>>
>> I guess the problem is that CMake is operating from a separate binary
>> tree as its base,
>> thus it obviously needs to pass fu
Re: [CMake] Cmake absolute paths with gcc, __FILE__ , and logging
2013/1/4 Andreas Mohr :
> Hi,
>
> On Fri, Jan 04, 2013 at 11:47:40AM -0500, cmake-requ...@cmake.org wrote:
>> Date: Fri, 4 Jan 2013 16:58:05 +0100
>> From: Willy Lambert
>
>> Hi all,
>>
>> Short Story :
>>
>> I am trying to convert an existing project from Manual Makefiles to
>> Cmake for building it.
>> We have a logger that rely on the __FILE__ define to say which file is
>> "writing" into the log but this is broken by the CMake default
>> behavior using absolute paths.
>> So I wonder if there is any way to have the file name in the code to
>> be able to log "Error : line XXX in file.cpp".
>>
>>
>>
>>
>> Long Story :
>>
>>
>>
>> So I have for instance a source /home/me/src/main.cpp, compiled with
>> relative paths "gcc -o main.cpp".
>> So the logger say "Error : line XXX in main.cpp".
>
> I'm afraid given the discussion at
> "Short form of __FILE__"
> http://bytes.com/topic/c/answers/453661-short-form-__file__
>
> the onus is on your project since it seems to be relying on
> seemingly rather volatile (non-standardized) behaviour of the __FILE__ macro
> (compilers seem to be free to pass on either a file's basename only
> or a relative path or even a FQPN).
Depends what you listen under standard. In my case it's standrd with
GNU tools. If you know how I could log filename + line number in a
standardized way let me know (or point links), I'll be very happy for
that. For now, I'm only expected my project working with GNU, and only
it (which is rather by necessity than by choice).
> And now that one is using a CMake build which needs to do builds from
> an entirely separate binary tree referencing source files in a
> foreign source tree (thus having a justified reason for needing to
> specify paths in full),
Yes and no. Yes, CMake has to manage a "source root dir" and a "binary
output dir" (and maybe a relative path from source to build ?), but
I'm not sure that you *need* it to build (see the
CMAKE_USE_RELATIVE_PATHS option that is already working on simple
cases). In my case, it's a "classical" CMake tructure :
myproject/
So it's a strong reason in current implementation, not sure it is
justified. Nevertheless I'm aware that as all free project it has
limitation, lack of contributions, etc, ... what I mean is that I'm
not sure that the onus of this is *only* my project.
I have 3 solutions (in this order of priority) :
_ extending Cmake
_ finding a hack
_ changing log system (for an obvious reason you can't switch easily
an existing project regarding log because there are lot of work to do)
> these improper assumptions in your project
> seem to fall flat on their face, since gcc chooses to prefer to pass on
> as much information to the __FILE__ macro as it can get
> about the file location (i.e., full path).
It's not really improper since I choosed GNU gcc, so everything is
behaving as expected. What is not behaving as expected (on my point of
view, with is relative), the improper assumption is that Cmake doesn't
hide
>
> Since the problem is thus firmly located on the source code side
> (i.e. its assumptions about __FILE__),
> I'd suggest treating the problem right there,
> using e.g. the discussion's strrchr() solution
> ("workaround"?) to achieve a slightly improved guarantee of gaining
> sufficiently constant output format (but note that Keith Thompson noted
> that the C language itself does not have any business dealing with path
> separator definitions).
>
>
>> I tried to use the suggested trigger "set_source_files_properties" to
>> define my own __FILE__ but it doesn't works with included files (it
>> shows main.cpp instead oh dummy.hpp)
>> http://www.cmake.org/pipermail/cmake/2011-December/048281.html
>>
>> So this way is a dead end because the compilator (and the one that
>> creates its command line) is the only one to be aware of this
>> information.
>>
>> Beside that, as I would really like to simplify the "VERBOSE=2 make"
>> output to be able to debug what CMake generates I currently have
>> plenty of path with 20 or more folder level including many "../..", I
>> am looking on making CMake giving relatives paths to gcc.
>
> I guess the problem is that CMake is operating from a separate binary
> tree as its base,
> thus it obviously needs to pass full paths to the source files to the
> compiler,
> to get to the "other" source dir "over there".
> The alternative would be to have cwd set to the source tree directory
> when launching gcc, to be able to specify source file arguments
> as file-only
> (the -o object file argument however should be able to support full paths
> without any negative effects, right?).
>
>
>> I have seen some thread about the use of CMAKE_USE_RELATIVE_PATHS, but
>> it seems that it is not working, and maybe with no will to support
>> this (is that true ?)
>> http://cmake.3232098.n2.nabble.com/CMAKE-USE-RELATIVE-PATHS-td4042914.html
>
> I'm actually rather interested in CMAKE_USE_RELATIVE_PATHS myself,
> since I'd like to be able to generate a (semi-static) su
[CMake] Selective build and install of subfolders
Hello list, I have a project with subfolders that should be selectively built and installed. The problem ist that there are various dependencies between them. At the moment I have a list-variable that contains the targets I want to be built and the folders are included depending on this list: $ cmake -DWANTED="this;that" A folder is included with ADD_SUBDIRECTORY if it is explicitly named in the list or is needed as dependency of another target - done with multiple LIST(FIND) commands. This way I'm functionally recreating the dependency list that is also built by ADD_DEPENDENCIES and TARGET_LINK_LIBRARIES. I searched the documentation for a better solution, but found only these things that seem related at first glance but don't do what I want: - Using EXCLUDE_FROM_ALL in ADD_SUBDIRECTORY, ADD_EXECUTABLE or ADD_LIBRARY. This should handle dependencies, but the docs say: "Installing a target with EXCLUDE_FROM_ALL set to true has undefined behavior." - Using COMPONENT in INSTALL commands. Does not affect compilation, just installation and does not handle dependencies. So my question: Am I missing something or is it not possible to do selective build and install without the fuss of recreating the dependencies? Thanks Stefan -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake absolute paths with gcc, __FILE__ , and logging
2013/1/7 Willy Lambert :
> 2013/1/4 Gregor Jasny :
>> Hello Willy,
>>
>> On 1/4/13 4:58 PM, Willy Lambert wrote:
>>> I am trying to convert an existing project from Manual Makefiles to
>>> Cmake for building it.
>>> We have a logger that rely on the __FILE__ define to say which file is
>>> "writing" into the log but this is broken by the CMake default
>>> behavior using absolute paths.
>>> So I wonder if there is any way to have the file name in the code to
>>> be able to log "Error : line XXX in file.cpp".
>>
>> This is somewhat hackish and should be surrounded by a check for the
>> Makefile generator:
>>
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__FILENAME__='\"$(subst
>> ${CMAKE_SOURCE_DIR}/,,$(abspath $<))\"'")
>>
>> Thanks,
>> Gregor
>>
>
> Thanks ! This is working and is a great solution for us. CMake is in
> love with abspath anyway, so whatever I'll do, it'll be hackish.
>
> I wasn't aware that CMake was letting us hacking with make likewise. I
> agree it is not a clean way but when it is the only solution it is a
> good exit gate when converting project from makefiles. Is this
> features expected by CMake or is it a un-wanted bug ? May I rely on
> Cmake kepping this behavior in futur versions.
>
eh, in fact it works only for the cpp file. But included files are
not stated correctly (case of inlined functions)...
But it's a step.
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake absolute paths with gcc, __FILE__ , and logging
2013/1/4 Gregor Jasny :
> Hello Willy,
>
> On 1/4/13 4:58 PM, Willy Lambert wrote:
>> I am trying to convert an existing project from Manual Makefiles to
>> Cmake for building it.
>> We have a logger that rely on the __FILE__ define to say which file is
>> "writing" into the log but this is broken by the CMake default
>> behavior using absolute paths.
>> So I wonder if there is any way to have the file name in the code to
>> be able to log "Error : line XXX in file.cpp".
>
> This is somewhat hackish and should be surrounded by a check for the
> Makefile generator:
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__FILENAME__='\"$(subst
> ${CMAKE_SOURCE_DIR}/,,$(abspath $<))\"'")
>
> Thanks,
> Gregor
>
Thanks ! This is working and is a great solution for us. CMake is in
love with abspath anyway, so whatever I'll do, it'll be hackish.
I wasn't aware that CMake was letting us hacking with make likewise. I
agree it is not a clean way but when it is the only solution it is a
good exit gate when converting project from makefiles. Is this
features expected by CMake or is it a un-wanted bug ? May I rely on
Cmake kepping this behavior in futur versions.
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
