[cmake-developers] [CMake 0015369]: file(STRINGS file VAR) fails to read entire file
The following issue has been SUBMITTED.
==
https://public.kitware.com/Bug/view.php?id=15369
==
Reported By:Joakim Söderberg
Assigned To:
==
Project:CMake
Issue ID: 15369
Category: CMake
Reproducibility:always
Severity: major
Priority: high
Status: new
==
Date Submitted: 2015-01-23 14:32 EST
Last Modified: 2015-01-23 14:32 EST
==
Summary:file(STRINGS file VAR) fails to read entire file
Description:
I am experiencing some weird issues with file(STRINGS.
It fails to read my entire file. The file is 2529 lines long, but CMake only
read 1885. Or well it reads the entire file, but then stops splitting it up into
lines, instead the last list entry consists of all the lines between 1885-2529.
Steps to Reproduce:
cmake -DFILE=thefile.gcov -P testscript.cmake
testscript:
file(STRINGS ${FILE} LIST)
list(LENGTH LIST LIST_COUNT)
message(${LIST_COUNT})
Additional Information:
I have not been able to test with a later CMake yet. But I hope there is some
workaround for this for older versions as well.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-01-23 14:32 Joakim SöderbergNew Issue
2015-01-23 14:32 Joakim SöderbergFile Added: thefile.gcov
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
On 01/22/2015 11:50 AM, Raffi Enficiaud wrote:
I can also do a pull request if you prefer,
As described in CONTRIBUTING.rst a patch here is preferred.
I've fetched your branch from https://github.com/raffienficiaud/CMake
Here are some comments.
Please wrap text in the documentation blocks of the FindMatlab
module to fit in 79 columns.
#find_package(Matlab
# [VERSION]
# [REQUIRED]
# [COMPONENTS component1 [component2]])
Individual find modules don't need to summarize the find_package
signature. Documentation of components and versions can just
refer to the :command:`find_package` command and name the options.
# .. note:
#
# The version above is the Matlab version...
The note text needs to be indented to be part of the note. The same
goes for all the variable and command documentation inside explicit
markup directives like .. variable:: and .. command::.
# User defined variables
# --
This section should be called something like Module Input Variables
and have intro wording like Users or projects may set the following
variables to configure this module behavior..
# Variables defined by the module
# ---
This section should distinguish between cache entries and output
variables. See FindJsonCpp for an example.
# Provided macros
# ---
Generally we try to use functions with set(... PARENT_SCOPE).
Also on the endmacro() and endfunction() calls please drop the
command name.
# WARNING: this thing pollutes the CMAKE_FIND_LIBRARY_PREFIXES global
variable.
# Should it be restored afterwards? Is there a more appropriate way to do
that?
set(CMAKE_FIND_LIBRARY_PREFIXES ${CMAKE_FIND_LIBRARY_PREFIXES}
${_matlab_lib_prefix_for_search})
This should be handled with a save/restore.
# The function arguments are:
Please use definition lists instead of bullet lists for function
argument documentation.
The copyright year should be 2014-2015 since we've spilled into
that range. There is no need for copyright notices in the
Tests/RunCMake test cmake code because there no creative input
in that boilerplate.
Please remove all trailing whitespace and make sure the files are
committed with LF newlines and not CRLF newlines (including tests).
Also make sure all files end in a newline (but not trailing blank
lines).
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding an option for relative compiler invocations
On 01/22/2015 04:46 AM, Michael Enßlin wrote:
(1.2) Using compile-time string manipulations to sanitize the filename.
Due to limitations of C++, this requires template metaprogramming,
leading to unreasonable complexity and compile times.
See below.
Over the last several decades, at least on the POSIX platform, it has
become common practice to invoke compilers with relative file paths
This is only true for in-source builds. CMake recommends out-of-source,
and then full paths are much more reliable. Even if one used relative
paths then your messages would still have a bunch of ../ in them for
an out-of-source build. Therefore I'll assume you're using in-source
builds.
Side note: To make relative paths behave right with __FILE__ you would
also need all include paths (-I) to be relative. Otherwise headers will
still get full paths. This would require much more work than just
trying to get compile lines to refer to source files with a relative
path.
So, assuming you have an in-source build then all sources and headers
must sit under a single prefix (the top of the source tree). With that
you can do something like:
string(LENGTH ${CMAKE_SOURCE_DIR}/ SRC_DIR_LEN)
add_definitions(-DSRC_DIR_LEN=${SRC_DIR_LEN})
and then in the source code do:
#define MY__FILE__ (__FILE__+SRC_DIR_LEN)
That will give you a compile-time constant __FILE__ with a relative path
and no runtime overhead. Use MY__FILE__ in your log macros.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding an option for relative compiler invocations
Hi, thanks for your reply. I am using an out-of-source build, and my build system even contains rules to explicitly prohibit in-source builds. To make __FILE__ behave correctly, you'd have to invoke the compiler with a different cwd. A generated line in build.make, which currently looks like this: cd /home/mic/git/openage/.bin/gcc-release-O2/cpp /usr/bin/g++ $(CXX_DEFINES) $(CXX_FLAGS) -o CMakeFiles/openage.dir/engine.cpp.o -c /home/mic/git/openage/cpp/engine.cpp would need to be changed to cd /home/mic/git/openage /usr/bin/g++ $(CXX_DEFINES) $(CXX_FLAGS) -o /home/mic/git/openage/.bin/gcc-release-O2/cpp/CMakeFiles/openage.dir/engine.cpp.o -c cpp/engine.cpp The solution I'm currently using is similar to the one you're suggesting; note that your suggestion can lead to misleading debug messages or even undefined behavior in the event that __FILE__ does not start with CMAKE_SOURCE_DIR for whatever reason. I'm not using any non-library include paths, so the include issue doesn't apply to my. ~ Michael signature.asc Description: OpenPGP digital signature -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FeatureSummary: Fix wrong bracket
On 01/22/2015 05:55 PM, Christoph Grüninger wrote: please find attached a small patch to change a ] to a ). Applied, thanks: FeatureSummary: Fix bracket in documentation. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b79d8f29 -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015370]: find_path MinGW not working while find_library does
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15370
==
Reported By:Lectem
Assigned To:
==
Project:CMake
Issue ID: 15370
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-01-23 19:18 EST
Last Modified: 2015-01-23 19:18 EST
==
Summary:find_path MinGW not working while find_library does
Description:
I couldn't get most of my libraries detected with find_package.
I figured out that the libraries files were found but not the headers.
For example :
find_path(GLEW_INCLUDE_DIR GL/glew.h)
will not work while
find_library(GLEW_LIBRARY glew32)
does.
FIND_PACKAGE(GLEW)
Does also set GLEW_LIBRARY and GLEW_LIBRARIES but not GLEW_INCLUDE_DIR.
Steps to Reproduce:
FIND_PACKAGE(GLEW)
IF(GLEW_FOUND)
MESSAGE(STATUS GLEW found.)
MESSAGE(STATUS Detected GLEW path is : ${GLEW_LIBRARIES})
ENDIF(GLEW_FOUND)
IF(GLEW_LIBRARIES)
MESSAGE(STATUS Detected GLEW_LIBRARIES path is : ${GLEW_LIBRARIES})
ENDIF(GLEW_LIBRARIES)
IF(GLEW_INCLUDE_DIRS)
MESSAGE(STATUS Detected GLEW_INCLUDE_DIRS path is : ${GLEW_INCLUDE_DIRS})
ELSE(GLEW_INCLUDE_DIRS)
MESSAGE(STATUS Couldn't find GLEW_INCLUDE_DIRS)
ENDIF(GLEW_INCLUDE_DIRS)
==
Issue History
Date ModifiedUsername FieldChange
==
2015-01-23 19:18 Lectem New Issue
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
