Re: [cmake-developers] automatically download library

2015-10-08 Thread Ryan Schmidt

On Oct 8, 2015, at 10:06 AM, Marsel Galimullin wrote:

> The idea is that CMake has possibility to contact with package managers for 
> download necessary libraries.
> If “find_package” can’t find a library, it need to call apt-get install.
> Example:
>auto_downland(apt-get)
>find_package (Boost COMPONENTS system thread REQUIRED)

I understand the idea, and I'm telling you that if you need this for your own 
personal project -- one that will never be included in a package management 
system -- then do whatever you like. But if you are proposing this as something 
that should be included in cmake, and you are suggesting that it could be used 
by any project that wants to -- even in projects that might someday be included 
in a package management system -- then I can tell you that this would not be 
welcomed by the people who maintain those package management systems. I am such 
a person. If I were tasked with the request to add to my package management 
system a project that wanted to control the installation of its own 
dependencies, or that in some other way tried to be in charge of downloading 
its dependencies, I would either have to rip all that code out, or more likely 
I would reject the request to add that project as being too labor-intensive. It 
is the package management system's job to download and install dependencies, 
not the job of the project's build system.

-- 

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] automatically download library

2015-10-06 Thread Ryan Schmidt

On Oct 6, 2015, at 7:22 AM, Марсель Галимуллин wrote:

> I'm student of the University LETI and as a masrer's thesis I want to develop 
> an extension to CMake. It is expected that this extension will automatically 
> download missing library if instruction such as «find_package (Boost 
> COMPONENTS system thread REQUIRED)» can not find the package. Could you give 
> me some advices where to begin and which the best direction to design, 
> develop and whether to do it?

If you need that for some special purpose, go for it, but it's probably not a 
behavior most users would expect, and it's definitely a behavior that would 
have to be disabled in any software installed by a package management system. 
(The package management system would want to be in control of what gets 
downloaded.)


-- 

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] cmake fails to identify C and CXX compiler when building universal

2015-09-29 Thread Ryan Schmidt
On Sep 29, 2015, at 1:54 AM, Nils Gladitz wrote:

> Is it possible that beyond setting CMAKE_OSX_ARCHITECTURES the project also 
> tries to manually add -arch flags to CFLAGS/CXXFLAGS?
> 
> The test binary produced for compiler identification with just 
> CMAKE_OSX_ARCHITECTURES set is not a fat binary for me and identification is 
> successful (CMake 3.3.2).
> 
> Manually adding "-arch x86_64 -arch i386" to the compiler flags breaks this 
> since now the test binary itself is also fat.

You are correct: in addition to giving cmake the 
-DCMAKE_OSX_ARCHITECTURES="x86_64;i386" argument, MacPorts includes "-arch 
x86_64 -arch i386" in the CFLAGS, CXXFLAGS, and LDFLAGS environment variables. 
I am not certain, but I think the only reason why we are doing this for 
cmake-using ports is that we do this for all ports, and no code was ever added 
to override this for cmake-using ports. Perhaps this didn't cause problems 
before, or we never noticed it caused problems before. I will work adding code 
to MacPorts to remove these flags for cmake-using ports. Thanks for the 
suggestion.

-- 

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 fails to identify C and CXX compiler when building universal

2015-09-28 Thread Ryan Schmidt
Hello, I am a developer with the MacPorts package management system, and I want 
to report to you a bug in cmake 3.3.2 that affects OS X.

I was going to file a bug report in your issue tracker, but the bright yellow 
box at the top of the "report issue" page made it sound like I should send my 
report here instead.

The problem is that cmake cannot identify the compiler, when compiling any 
project (that uses cmake) universally (i.e. for more than one architecture, 
e.g. for both x86_64 and i386):

-- cmake version 3.3.2
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown

This could cause programs that rely on identifying the compiler to either build 
incorrectly or even (e.g. in the case of x265) to fail to build at all. For 
cross-referencing purposes, this problem was previously reported to the 
MacPorts project here:

https://trac.macports.org/ticket/48331

The problem does not occur when compiling non-universally (i.e. for only a 
single architecture, e.g. for only x86_64):

-- The C compiler identification is AppleClang 7.0.0.772
-- The CXX compiler identification is AppleClang 7.0.0.772

I found that in CMakeDetermineCompilerId.cmake, cmake compiles a test program 
(CMAKE_DETERMINE_COMPILER_ID_BUILD) which defines certain strings that describe 
the compiler, and then examines the strings in the compiled a.out file 
(CMAKE_DETERMINE_COMPILER_ID_CHECK). If the file contains more than one 
"INFO:compiler[...]" string, cmake assumes something went wrong and sets 
COMPILER_ID_TWICE to 1 which causes the compiler id to be forgotten.

The problem is that when building universal, the a.out file produced by the 
test will contain multiple copies of the strings -- once for each architecture. 
What the compiler does for you when you use multiple -arch flags is to compile 
the file separately, once for each architecture, then glue the separate files 
together into a single file (using the lipo program), so naturally such a file 
will contain multiple copies of any strings. This is not a bug; this is how 
universal binaries work. The bug is that cmake considers this valid condition 
to be erroneous.

Here is an example of the duplicated strings:

$ lipo -info build/CMakeFiles/3.3.2/CompilerIdC/a.out 
Architectures in the fat file: work/build/CMakeFiles/3.3.2/CompilerIdC/a.out 
are: x86_64 i386
$ strings -arch all build/CMakeFiles/3.3.2/CompilerIdC/a.out 
INFO:compiler[AppleClang]
INFO:platform[Darwin]
INFO:arch[]
INFO:compiler_version[0007...0772]
INFO:compiler[AppleClang]
INFO:platform[Darwin]
INFO:arch[]
INFO:compiler_version[0007...0772]

(I know cmake uses its internal FILE(STRINGS) command, not the strings program, 
but I presume they are similar.)

I was able to get cmake to correctly identify the compilers even when building 
universal by simply removing the COMPILER_ID_TWICE stuff from 
CMakeDetermineCompilerId.cmake, but perhaps you want something more elegant 
that verifies that if there are multiple definitions of a particular info line, 
all the definitions are the same.

-- 

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