Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

2019-09-19 Thread Juan E. Sanchez 

Hello,

Perhaps you can start by not using the .bat scripts and using the .exe 
instead.  You can run cmake from a visual studio environment, and 
instead of invoking a visual studio environment for each command.


And to build from your script:
cmake --build .

Regards,

Juan


On 9/19/19 12:59 PM, Joao Pedro Abreu De Souza wrote:

Now, with this toolchain file:
-start of toolchain file---
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
#set(CMAKE_C_COMPILER cl.exe)
#set(CMAKE_CXX_COMPILER cl.exe)

set(CMAKE_C_COMPILER 
"${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/cl.bat")

set(CMAKE_CXX_COMPILER "${CMAKE_C_COMPILER}")

# Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)


set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")



#set(CMAKE_STATIC_LINKER link.exe)
#set(CMAKE_LINKER link.exe)
#set(CMAKE_SHARED_LINKER link.exe)

set(CMAKE_STATIC_LINKER 
"${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/link.bat")

set(CMAKE_LINKER ${CMAKE_STATIC_LINKER})
set(CMAKE_SHARED_LINKER ${CMAKE_STATIC_LINKER})


set(CMAKE_AR ${CMAKE_LINKER})

set(CMAKE_C_COMPILER_ID "porquePreciseiDeUmBat")
-stop of toolchain file---

using this cl.bat
start of cl.bat-
pushd
"C:/Program Files (x86)/Microsoft Visual 
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"

popd
cl.exe %*
stop of cl.bat-

and link.bat in the same spirit but with link.exe instead of cl.exe, I 
can execute cmake, ninja, but the main.exe don't are on build/src/main



When I look on CMakeError.log on build directory, can look

---start of CMakeError.log--
C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles>more 
CMakeError.log
Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Checking whether the C compiler is IAR using "" did not match "IAR .+ 
Compiler":


C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program 
Files (x86)/Microsoft Visual 
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"

**
** Visual Studio 2017 Developer Command Prompt v15.9.16
** Copyright (c) 2017 Microsoft Corporation
**
[vcvarsall.bat] Environment initialized for: 'x64_x86'
Checking whether the C compiler is IAR using "" did not match "IAR .+ 
Compiler":


C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program 
Files (x86)/Microsoft Visual 
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"

Re: [CMake] Linking on OSX

2019-06-04 Thread Juan E. Sanchez 

Hello,

It looks like you are making progress.  Note that to use the gcc-8 and 
g++-8 compilers from brew, you need to have include files in 
/usr/include.  Otherwise you get strange errors about missing _stdio.h, 
etc.  I believe in another thread, someone suggests how to make sure the 
headers get put in the right place.


I looked and found curses.h (not ncurses.h) here.
/usr/include/curses.h.

Regards,

Juan


On 6/4/19 12:56 PM, Bryan Christ wrote:

Juan,

Thanks for your suggestions.  I went through that thread pretty 
thoroughly trying all of the recommended tips and, unfortunately, 
nothing seemed to work.  I also tried running that open command you 
cited, but there are still no includes for ncurses in /usr/include or 
/usr/local/include.  In fact /usr/include doesn't even exist on this 
system (mojave).


On Mon, Jun 3, 2019 at 5:27 PM Juan E. Sanchez <mailto:juan.e.sanc...@gmail.com>> wrote:


Hello,

According to this:
https://github.com/neovim/neovim/issues/9050

It looks like macOS made it so you have to do something like this:
open

/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

for libraries and includes to be put into /usr.

Regards,

Juan


On 6/3/19 5:16 PM, Bryan Christ wrote:
 > New to this mailing list so I hope I'm asking this in the right
venue...
 >
 > I'm trying to port my application (a program and a shared
library) to
 > OSX.  It was rather easy to modify my CMake script to go from
Linux and
 > add in FreeBSD.  OSX is giving me a lot of problems though.
 >
 > First of all find_package() doesn't seem to find the ncurses.dylib
 > installed by XCode as it test for wsyncup().  For whatever
reason, that
 > test fails.  The default location for the library is pretty sane
 > (/usr/lib/) but the include file for ncurses is about 9
directories deep
 > inside of XCode's install directory.  Lots of problems here so I
decided
 > to look at the symbol linkage for htop and see what it does.  It
links
 > to a different version that got pulled down via homebrew in
 > /usr/local/opt/ncurses/lib (and include respectively)
 >
 > Is there a way to force CMake to link to the library found there
instead
 > of in /usr/lib/ ?
 >
 > --
 > Bryan
 > <><
 >

-- 


Powered by www.kitware.com <http://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:
https://cmake.org/mailman/listinfo/cmake



--
Bryan
<><


--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Linking on OSX

2019-06-03 Thread Juan E. Sanchez 

Hello,

According to this:
https://github.com/neovim/neovim/issues/9050

It looks like macOS made it so you have to do something like this:
open 
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg


for libraries and includes to be put into /usr.

Regards,

Juan


On 6/3/19 5:16 PM, Bryan Christ wrote:

New to this mailing list so I hope I'm asking this in the right venue...

I'm trying to port my application (a program and a shared library) to 
OSX.  It was rather easy to modify my CMake script to go from Linux and 
add in FreeBSD.  OSX is giving me a lot of problems though.


First of all find_package() doesn't seem to find the ncurses.dylib 
installed by XCode as it test for wsyncup().  For whatever reason, that 
test fails.  The default location for the library is pretty sane 
(/usr/lib/) but the include file for ncurses is about 9 directories deep 
inside of XCode's install directory.  Lots of problems here so I decided 
to look at the symbol linkage for htop and see what it does.  It links 
to a different version that got pulled down via homebrew in 
/usr/local/opt/ncurses/lib (and include respectively)


Is there a way to force CMake to link to the library found there instead 
of in /usr/lib/ ?


--
Bryan
<><



--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Can't open module file *.mod

2019-02-05 Thread Juan E. Sanchez 
It has been several months since I looked at this.  I seem to remember 
setting dependencies between libraries containing modules, using 
something like target_link_libraries.  I think that cmake was capable of 
detecting dependencies between files in the same library.  I think it 
relied on the use of the USE statement.


I think

Regards,

Juan


On 2/5/19 8:29 PM, Petr Penzin wrote:
When I ran into the same issue, my workaround was to use file properties 
to set dependencies between files, but I don't think it is very robust 
solution. Would be curious to hear if there is a better way to do it.


Best,

Petr


On 2/5/19 2:55 PM, Guido Giuntoli wrote:

Hi I have a Fortran project with the following order

src/module_1.f90 (Fortran Modules)
src/module_2.f90
src/... (more files)

file(GLOB SOURCES src/*.f90)
add_executable(MyExec SOURCES)

module_1 depends on module_2 and when is compiling module_1.f90 I get 
the dependency error :


Fatal Error: Can't open module file ‘module_2.mod’ :for reading at 
(1):  No existe el fichero o el directorio (*The file does not exist*).


Thanks, Guido.






--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Make errors when running ./bootstrap in Ubuntu 12.04

2018-12-14 Thread Juan E. Sanchez 
The original poster is using Ubuntu 12.04, so a precompiled binary might 
not work if it targeted a newer system.  Ubuntu 12.04 is obsolete and no 
longer supported by Canonical and is a huge risk for production systems.


I would suggest the original poster try installing gnu gcc c++ instead 
of clang.


Please see:
https://askubuntu.com/questions/26498/how-to-choose-the-default-gcc-and-g-version

Regards,

Juan

On 12/14/18 11:02 AM, Eric Noulard wrote:

Did you try to pick a pre-compiled version of CMake?
https://cmake.org/download/

https://github.com/Kitware/CMake/releases/download/v3.13.2/cmake-3.13.2-Linux-x86_64.tar.gz
CMake is statically linked so installing a binary should work.

Le ven. 14 déc. 2018 à 17:48, Paul Jeffries > a écrit :


Dear list,

I ultimately want to install a program called DosageConvertor that
requires a version of cmake that is 3.2 or later. Therefore, I am
trying to install a more recent version of cmake since the current
version is 2.8.7.

When I run ./bootstrap, I get a message that there were problems
running make: 2 errors generated. make: ***
[cmAddCustomCommandCommand.o] Error 1 (I have added the complete
output below.)

I searched and found no clear solution to this problem. I did see
that std should be set to gnu++11, but my output has “std=gnu++1y”.

I specified the compiler because when I ran ./bootstrap by itself, I
got an error message that there was no C++ compiler. Did I choose
the wrong compiler? Am I missing a library?

Any help would be appreciated.

Paul

|paul@paul-VirtualBox:~/cmake-3.13.1$ CC=gcc ./bootstrap && make &&
sudo make install|
|-|
|CMake 3.13.1, Copyright 2000-2018 Kitware, Inc. and Contributors|
|C compiler on this system is: gcc |
|C++ compiler on this system is: clang++ -std=gnu++1y |
|Makefile processor on this system is: make|
|clang++ has setenv|
|clang++ has unsetenv|
|clang++ does not have environ in stdlib.h|
|clang++ has stl wstring|
|clang++ has |
|-|
|clang++ -std=gnu++1y -I/home/paul/cmake-3.13.1/Bootstrap.cmk
-I/home/paul/cmake-3.13.1/Source -I/home/paul/cmake-
3.13.1/Source/LexerParser |
|-I/home/paul/cmake-3.13.1/Utilities -c
/home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx -o
cmAddCustomCommandCommand.o |
|In file included from
/home/paul/cmake-3.13.1/Source/cmAddCustomCommandCommand.cxx:9:|
|In file included from
/home/paul/cmake-3.13.1/Source/cmCustomCommand.h:9: |
|/home/paul/cmake-3.13.1/Source/cmListFileCache.h:127:3: error:
exception specification of explicitly defaulted move constructor
does not match the cmListFileBacktrace(cmListFileBacktrace&&) //
NOLINT(clang-tidy)|
|||^ /home/paul/cmake-3.13.1/Source/cmListFileCache.h:130:24: error:
exception specification of explicitly defaulted move assignment
operator does not match the calculated one cmListFileBacktrace&
operator=(cmListFileBacktrace&&) // NOLINT(clang-tidy)|
|||^|
|2 errors generated.|
|make: *** [cmAddCustomCommandCommand.o] Error 1|
|-|
|Error when bootstrapping CMake:|
|Problem while running make|
|-|
|Log of errors:
/home/paul/cmake-3.13.1/Bootstrap.cmk/cmake_bootstrap.log|
|-|
|paul@paul-VirtualBox:~/cmake-3.13.1$ |




-- 


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:
https://cmake.org/mailman/listinfo/cmake



--
Eric



--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Using Different Computers for cmake and ctest

2018-08-06 Thread Juan E. Sanchez 

Hi,

CTest should work.  You would just need to set the paths to the 
executable you want to test.  In my case, I have my tests in a different 
repository than my source code.


Regards,

Juan

On 8/6/18 3:00 PM, Alexander Neundorf wrote:

On 2018 M07 18, Wed 09:49:47 CEST Brian S wrote:

I currently use cmake/ctest to build and test my software. The software is
C++/CUDA. During the build step I don't need a GPU but in the test step I
do. I would like to build the code with cmake on a cluster with many CPUs
and then run the tests using ctest on a target machine with a GPU. Is this
possible?


as far as I know this is currently not possible.
I would also like to do that, to test the same executable on a set of
different clusters (or at least with a different number of nodes. For that
there is no need to rebuild the project multiple times.

For tests, cmake generates CTestTestFile.cmake.
These are executed when running a test.
Copying the buildtree somewhere and then see what happens when you run ctest.
E.g. RPATHs probably won't be correct. The tests may also have references into
the source directory.

Having a nice way to do this properly would be nice IMO :-)

Alex



--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] specifying path for license file for commercial compiler?

2018-07-08 Thread Juan E. Sanchez 

Hi,

Could you create a simple compiler wrapper script, and point the 
CMAKE_*_COMPILER variables there:


#!/bin/bash
export INTEL_LICENSE_FILE=/usr/local/intel/license
/path/to/ifort "$@"

Regards,

Juan


On 7/8/18 8:41 PM, Clune, Thomas L. (GSFC-6101) wrote:
Unfortunately, I cannot dictate where the sysadmins are putting the 
license file. I can of course put a copy in  /home//Licenses 
which is another location that Intel looks by default.   And if there is 
no better solution, I will provide instructions to all of our developers 
on making copies themselves on our various development platforms.    Or 
at that point I’ll just ask them all to set the environment variable in 
their shell startup files.


I’m still a bit astonished that something as simple as this is 
essentially unsupported.    It is particularly frustrating as try_run() 
successfully exercises the compiler while the run-of-the-mill compiler 
invocations under make do not. Sort of makes sense though.  CMake 
launches try_run() in a subshell and therefore it sees the env variable 
I am setting with set(ENV…).   OTOH, the subsequent make commands are 
not subshells and therefore need a separate mechanism to see that env 
variable.


*From: *Stephen McDowell 
*Date: *Saturday, July 7, 2018 at 2:25 AM
*To: *Marc CHEVRIER 
*Cc: *"Clune, Thomas L. (GSFC-6101)" , CMake 
MailingList 
*Subject: *Re: [CMake] specifying path for license file for commercial 
compiler?


I agree that a toolchain file is more appropriate, noting that typically 
modifying the environment variables is much more common for there's 
compilers (particularly using environment modules).


However, since you've started clearly you would rather not set the 
environment variables, there may be an easier "hack".


Intel also looks in /opt/intel/licenses for any .lic files. So if you 
want, you can just create a symbolic link or copy your license file there :)


On Fri, Jul 6, 2018, 10:49 PM Marc CHEVRIER > wrote:


May be using a toolchain file is more appropriate. See

https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html

Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101)
mailto:thomas.l.cl...@nasa.gov>> a écrit :

To use the Intel compiler, one must use an environment variable
that specifies the path to the license file.  E.g.,

     export INTEL_LICENSE_FILE=/usr/local/intel/license

Other commercial compilers use a very similar mechanism.    I
had hoped to capture such information in a cache file so that I
could avoid polluting the shell where I am invoking cmake:

     % cmake -C my-cache 

Such a cache file could  look like:

     set(CMAKE_Fortran_COMPILER

"/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort"
CACHE path "Fortran compiler")
     set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license"
CACHE path "Intel license")


Unfortunately, the compiler is not “seeing” the env variable and
complains that there is no license.     Is there a solution to
this, or am I forced to set the env variable each time I try to
build?







-- 


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:
https://cmake.org/mailman/listinfo/cmake

-- 


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:
https://cmake.org/mailman/listinfo/cmake





--

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

Re: [CMake] race condition with target_objects

2018-06-26 Thread Juan E. Sanchez 

Hello Brad,

Thanks for finding the issue.  I had simply replaced the shared library 
I was using with the name of the TARGET_OBJECTS generator.


The shared objects are great.  It helps me bypass Apple security issues 
when a system interpreter loads a shared library, which loads another 
shared library.


Regards,

Juan

On 6/26/18 1:34 PM, Brad King wrote:

On 06/26/2018 01:32 PM, Juan E. Sanchez wrote:

The likely problem is that the symdiff_objects and the symdiff_tcl are
in side-by-side directories.  They are both added using ADD_SUBDIRECTORY
one level up.  If I put symdiff_python before symdiff_tcl, then that
target will fail.  Please fix your Makefile generator.


Target dependencies are agnostic to the directories.  The ordering at
most matters for serial builds of independent targets.

While trying to reproduce this in a simple example I found the problem:

```
TARGET_LINK_LIBRARIES (symdiff_tcl $ 
${TCL_ARCHIVE})
```

That is not the way to reference an object library.

The documentation:

   
https://cmake.org/cmake/help/v3.12/manual/cmake-buildsystem.7.html#object-libraries

shows that `$` belongs in the list of *sources*,
not linked libraries.  You should be using:

```
add_library(symdiff_tcl SHARED ... $)
```

-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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] race condition with target_objects

2018-06-26 Thread Juan E. Sanchez 

Hi,

The likely problem is that the symdiff_objects and the symdiff_tcl are 
in side-by-side directories.  They are both added using ADD_SUBDIRECTORY 
one level up.  If I put symdiff_python before symdiff_tcl, then that 
target will fail.  Please fix your Makefile generator.


Regards,

Juan


On 6/26/18 10:58 AM, Brad King wrote:

On 06/25/2018 03:09 PM, Juan E. Sanchez wrote:

ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
TARGET_LINK_LIBRARIES (symdiff_tcl $ 
${TCL_ARCHIVE})

How do I tell cmake to wait?


Strange, our test suite covers that and the dependency appears.
The TARGET_OBJECTS generator expression evaluation has special
logic to forward the target-level dependency.


This is cmake 3.9.0-rc4


Please try a more recent version, perhaps an actual release.

-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:
https://cmake.org/mailman/listinfo/cmake

[CMake] race condition with target_objects

2018-06-25 Thread Juan E. Sanchez 

Hi,

I am getting a race condition when I do a parallel build.

Having an OBJECT library in one directory:
ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)

And then having that object library being used in another directory:
TARGET_LINK_LIBRARIES (symdiff_tcl $ 
${TCL_ARCHIVE})


Results in this error with a parallel build:
 15%] Building CXX object 
src/engine/CMakeFiles/symdiff_static.dir/EquationObject.o
make[2]: *** No rule to make target 
`src/engine/CMakeFiles/symdiff_objects.dir/EquationObject.o', needed by 
`src/tclcomp/libsymdifftcl.dylib'.  Stop.

make[2]: *** Waiting for unfinished jobs

Serial builds work fine.  How do I tell cmake to wait?  This is cmake 
3.9.0-rc4 running on os x with the makefile generator.


Regards,

Juan
--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] compiling for both python2 and python3

2018-06-25 Thread Juan E. Sanchez 

Hi,

What happens if you call FindBoost once for python 2 and once for python 
3?  Between invocations you could copy the boost variables to python 
specific variants.


FindBoost( . . . .)
SET(Boost_LIBRARY_DIRS_PYTHON2 ${Boost_LIBRARY_DIRS})
FindBoost( . . . .)
SET(Boost_LIBRARY_DIRS_PYTHON3 ${Boost_LIBRARY_DIRS})


Regards,

Juan


On 6/25/18 1:24 AM, Alexander Bürger wrote:

Hello Juan,

but there are also two boost-python versions required, one for python2 
and one for python3. I think it is not a good idea to reimplement the 
FindBoost logic.


Cheers,

Alexander Bürger
MET Norway
​




--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] compiling for both python2 and python3

2018-06-22 Thread Juan E. Sanchez 
I use the same source files to compile by setting 
TARGET_INCLUDE_DIRECTORIES for two similar targets.  The included 
Python.h provides the PY_MAJOR_VERSION macro to know if you are 
compiling for python 2 or 3.


https://github.com/devsim/devsim/blob/master/src/pythonapi/CMakeLists.txt

https://github.com/devsim/devsim/blob/master/src/pythonapi/PythonCommands.cc

I avoid using FIND_PACKAGE, and code my own PYTHON or PYTHON3 variables, 
like:

PYTHON_INCLUDE
PYTHON3_INCLUDE

in a specific cmake file for my configuration:

https://github.com/devsim/devsim/blob/master/cmake/centos_6.cmake

Regards,

Juan Sanchez

On 6/22/18 2:15 PM, Isaiah Norton wrote:



On Fri, Jun 22, 2018 at 4:36 AM Alexander Bürger > wrote:


Hi,

I am trying to find a good way to compile a python module for a c++
library using boost-python for both python2 and python3 in the same
compilation. So far, The only solution I found for using


The headers CMake needs to find are different depending on the selected 
version, because the CPython API changed between 2 and 3. The ABI is 
also not guaranteed to be stable within 3.x minor versions unless you 
set Py_LIMITED_API (see e.g. 
https://stackoverflow.com/questions/28830653/build-boost-with-multiple-python-versions).



FIND_PACKAGE(PythonInterp REQUIRED)
FIND_PACKAGE(PythonLibs REQUIRED)
FIND_PACKAGE(Boost REQUIRED COMPONENTS python # or python3)

with different python versions is to use one CMakeLists.txt per
python version, each in a subdirectory, and with almost equal
contents. I would appreciate suggestions for a better approach, with
less duplication.

Best regards,

Alexander Bürger
MET Norway

-- 


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:
https://cmake.org/mailman/listinfo/cmake





--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] find_library doesn't find .dll on windows

2018-06-01 Thread Juan E. Sanchez 
My understanding is that you are supposed to link against the .lib file, 
and the .dll is used at runtime.


From:
https://dev.mysql.com/doc/refman/5.7/en/c-api-building-clients.html

You link your code with either the dynamic or static C client library. 
On Windows, the static library is named mysqlclient.lib and the dynamic 
library is named libmysql.dll. In addition, the libmysql.lib static 
import library is needed for using the dynamic library. If the static C 
client library is used, the client application must be compiled with the 
same version of Visual Studio used to compile the C client library 
(which is Visual Studio 2013 for the static C client library built by 
Oracle).



Regards,

Juan


On 6/1/18 9:53 AM, Romain LEGUAY wrote:

Hi everyone,

I try to find MYSQL dynamic library on windows.
For this, I use the following command:

set(_PF86 "ProgramFiles(x86)")
find_library( MYSQL_LIBRARY
NAME "libmysql.dll"
PATHS "$ENV{PROGRAMFILES}/MySQL/*/lib"
   "$ENV{${_PF86}}/MySQL/*/lib"
   "$ENV{SYSTEMDRIVE}/MySQL/*/lib"
   NO_DEFAULT_PATH)

This command doesn't work on my computer (Windows 10 Pro x64, CMake 3.11.3).
If I remove the .dll extension, find_library find libmysql.lib which is 
in the same folder as libmysql.dll.


How to say to CMake to use the name I chosen?

Thank you!
Romain




--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to build CMake so it works on an older Linux?

2018-04-05 Thread Juan E. Sanchez 

The example I just sent was for building in centos 6, because 5 is gone.

docker run -it  --name centos6 centos:6 /bin/bash

Regards,

Juan

On 4/5/18 3:13 PM, Juan E. Sanchez wrote:

Hello,

Centos 5, Redhat 5 is EOL as of March 31, 2017.

Building cmake in docker:

cd /root;
curl -L -O https://cmake.org/files/v3.11/cmake-3.11.0.tar.gz;
tar xzvf cmake-3.11.0.tar.gz;
yum install -y centos-release-scl;
yum install -y devtoolset-6-gcc devtoolset-6-gcc-c++ 
devtoolset-6-libquadmath-devel devtoolset-6-gcc-gfortran;

source /opt/rh/devtoolset-6/enable;
cd cmake-3.11.0;
./bootstrap --prefix=/root/cmake --parallel=4;
make -j4;
make install;
cd /root;
tar czvf cmake.tgz;

Please note that cmake will silently ignore features for packages that 
haven't been installed into the image, (ncurses, curl).


Regards,

Juan

On 4/5/18 2:50 PM, Ben Sferrazza wrote:



On Thu, Apr 5, 2018 at 12:30 PM, Alexander Neundorf <neund...@kde.org 
<mailto:neund...@kde.org>> wrote:


    On 2018 M04 5, Thu 21:24:40 CEST Alexander Neundorf wrote:
    > On 2018 M04 5, Thu 16:15:17 CEST suzuki toshiya wrote:
    > > Dear Eric,
    > >
    > > # if anybody think "how C++11 environment should be prepared
    > > # on legacy GNU/Linux" is off-topic and should be discussed
    > > # in off-list, please let me know. I will do so.
    > >
    > > Eric Wing wrote:
    > > > Thanks for the responses. Yes, I just need this to run on 
Ubuntu 12.04
    > > > (and some other old Linux's in that era). Yes, I think the 
probably is

    > > > the libstdc++ dependency.
    > > >
    > > > As pointed out, it is really hard to get a newer compiler on 
Ubuntu
    > > > 12.04. I've been down this road before, and if memory 
serves, the gcc
    > > > bootstrapping process to get a newer compiler doesn't seem 
to work
    > > > with a compiler older than gcc 4.8. Same goes for clang, 
which also

    > > > weirdly relies on gcc 4.8 to bootstrap itself.
    > >
    > > At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, 
could

    > > build gcc-4.8.5 manually (without shared libstdc++, so confused
    > > dependency could be avoided). And, I could build cmake-3.11.0 
by it.

    > > Now I'm checking "make test".
    >
    > I have recently built a gcc 4.9.5 on Centos 5, i.e. gcc 4.1. 
There were no

    > issues after getting the configure flags right.

    4.9.4 I mean.
    You can see the flags here:

https://hub.docker.com/r/aneundorf/docker-centos5-build-svn-gcc/~/dockerfile/ 


<https://hub.docker.com/r/aneundorf/docker-centos5-build-svn-gcc/~/dockerfile/> 


    (but the docker image didn't build, it was killed by a dockerhub
    timeout).

    Alex


Were you able to actually build the newer versions of Cmake that 
require c++11 on Centos 5? I have built up a bootstrapped toolchain, 
following much of the guidance found in Linux From Scratch, on a 
Centos 5 system at work (which unfortunately cannot be upgrade due to 
the support of legacy software). The toolchain uses the latest gcc 
7.3.0, binutils 2.30, and glibc 2.19 (the latest version of glibc 
supported by the 2.6.18 kernel of Centos 5). Yet cmake complains that 
my toolchain does not support c++11. Which kernel and glibc version do 
you have on your Centos 5 box? Thank you.







--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to build CMake so it works on an older Linux?

2018-04-05 Thread Juan E. Sanchez 

Hello,

Centos 5, Redhat 5 is EOL as of March 31, 2017.

Building cmake in docker:

cd /root;
curl -L -O https://cmake.org/files/v3.11/cmake-3.11.0.tar.gz;
tar xzvf cmake-3.11.0.tar.gz;
yum install -y centos-release-scl;
yum install -y devtoolset-6-gcc devtoolset-6-gcc-c++ 
devtoolset-6-libquadmath-devel devtoolset-6-gcc-gfortran;

source /opt/rh/devtoolset-6/enable;
cd cmake-3.11.0;
./bootstrap --prefix=/root/cmake --parallel=4;
make -j4;
make install;
cd /root;
tar czvf cmake.tgz;

Please note that cmake will silently ignore features for packages that 
haven't been installed into the image, (ncurses, curl).


Regards,

Juan

On 4/5/18 2:50 PM, Ben Sferrazza wrote:



On Thu, Apr 5, 2018 at 12:30 PM, Alexander Neundorf > wrote:


On 2018 M04 5, Thu 21:24:40 CEST Alexander Neundorf wrote:
> On 2018 M04 5, Thu 16:15:17 CEST suzuki toshiya wrote:
> > Dear Eric,
> >
> > # if anybody think "how C++11 environment should be prepared
> > # on legacy GNU/Linux" is off-topic and should be discussed
> > # in off-list, please let me know. I will do so.
> >
> > Eric Wing wrote:
> > > Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04
> > > (and some other old Linux's in that era). Yes, I think the probably is
> > > the libstdc++ dependency.
> > >
> > > As pointed out, it is really hard to get a newer compiler on Ubuntu
> > > 12.04. I've been down this road before, and if memory serves, the gcc
> > > bootstrapping process to get a newer compiler doesn't seem to work
> > > with a compiler older than gcc 4.8. Same goes for clang, which also
> > > weirdly relies on gcc 4.8 to bootstrap itself.
> >
> > At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, could
> > build gcc-4.8.5 manually (without shared libstdc++, so confused
> > dependency could be avoided). And, I could build cmake-3.11.0 by it.
> > Now I'm checking "make test".
>
> I have recently built a gcc 4.9.5 on Centos 5, i.e. gcc 4.1. There were no
> issues after getting the configure flags right.

4.9.4 I mean.
You can see the flags here:

https://hub.docker.com/r/aneundorf/docker-centos5-build-svn-gcc/~/dockerfile/


(but the docker image didn't build, it was killed by a dockerhub
timeout).

Alex


Were you able to actually build the newer versions of Cmake that require 
c++11 on Centos 5? I have built up a bootstrapped toolchain, following 
much of the guidance found in Linux From Scratch, on a Centos 5 system 
at work (which unfortunately cannot be upgrade due to the support of 
legacy software). The toolchain uses the latest gcc 7.3.0, binutils 
2.30, and glibc 2.19 (the latest version of glibc supported by the 
2.6.18 kernel of Centos 5). Yet cmake complains that my toolchain does 
not support c++11. Which kernel and glibc version do you have on your 
Centos 5 box? Thank you.





--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to build CMake so it works on an older Linux?

2018-04-05 Thread Juan E. Sanchez 

Hello,

SHORT VERSION:

BTW, Ubuntu 12 is officially End of Life on April 28, 2017

http://releases.ubuntu.com/12.04/

So unless you are paying them for support, you should really upgrade to 
Ubuntu 14.


LONG VERSION:

I recommend starting a docker image of centos 6 in a newer version of 
Ubuntu.  This would be a virtual machine environment you can build a 
version with a newer compiler, g++, but with an older glibc.  The 
libstdc++ you link against would then be compatible with most modern 
distributions.


This is by getting the devtoolset-6 or devtoolset-7 tools provided by 
redhat.  You can communicate with me offline on how to do this, but in 
principle the installation of the compiler is this:


yum install -y centos-release-scl
yum install -y devtoolset-6-gcc devtoolset-6-gcc-c++ 
devtoolset-6-libquadmath-devel devtoolset-6-gcc-gfortran


Docker is freely available and used across the open source community to 
build for multiple linux versions.  It can be installed directly from 
ubuntu as a standard package.


You can then package the application, and it would more than likely run 
on your system.


Regards,

Juan

On 4/4/18 10:23 PM, Eric Wing wrote:

I just discovered that CMake no longer builds on my Ubuntu 12.04. I
need to build binaries that are compatible with that ABI.

I see that your binary distribution of CMake 3.11 still works on
Ubuntu 12.04. Can you tell me what you do to achieve this? What are
you doing for your official builds?

Are you just using -static-libstdc++ -static-libgcc for
CMAKE_CXX_FLAGS, or is there more?

(I just noticed that ldd shows that you don't have dependencies on
libssl, libcrypto, and libz, whereas I do.)

Thanks,
Eric



--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] fortran linking issue

2017-07-13 Thread Juan E. Sanchez 
It turns out these linker flags were being added by cmake.  To disable 
them, I had to:

unset(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES)

I was then able to use SET_TARGET_PROPERTIES to link into the static 
versions of the code I wanted.


This also fixed the issue for the case where I had a C++ exe with a 
Fortran library.  In this case, I only needed to use 
TARGET_LINK_LIBRARIES to bring in my static gfortran and quadmath libraries.


It turns out that libgfortran has its own link to libquadmath, so I was 
forced to statically link that as well.


Regards,

Juan



On 7/13/17 2:29 PM, Juan E. Sanchez wrote:
When I set the linker language of a fortran program to "C", it 
automatically links in -lgfortran, -lquadmath, -lm.


SET_TARGET_PROPERTIES(main_f PROPERTIES LINKER_LANGUAGE "C")

Unfortunately, that precludes me linking in static versions of  -lquadmath.

How do I tell CMAKE not to append these libraries when I change the 
LINKER_LANGUAGE to "C"?


Regards,

Juan


--

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

[CMake] fortran linking issue

2017-07-13 Thread Juan E. Sanchez 
When I set the linker language of a fortran program to "C", it 
automatically links in -lgfortran, -lquadmath, -lm.


SET_TARGET_PROPERTIES(main_f PROPERTIES LINKER_LANGUAGE "C")

Unfortunately, that precludes me linking in static versions of  -lquadmath.

How do I tell CMAKE not to append these libraries when I change the 
LINKER_LANGUAGE to "C"?


Regards,

Juan
--

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

Re: [CMake] fortran module name issue

2017-06-26 Thread Juan E. Sanchez 

Hi Burlen,

Thanks for your response, it inspired me to do something similar.

Starting with the non-processed files, I used the code below.  It also 
seems to track the mod file dependencies correctly, but I need to 
thoroughly test it.


Note that I had to use the cpp command with brew (on mac os x) to 
concatenate the tokens without spaces.  The linux cpp at work should 
also be able to handle the traditional-cpp required.


Regards,

Juan


PROJECT(foo)
ENABLE_LANGUAGE(CXX Fortran)

SET(TFILES foo baz)

SET(FFILES "")
FOREACH(I ${TFILES})
  SET(THISFILE ${I}_double.F)
ADD_CUSTOM_COMMAND (
  OUTPUT ${CMAKE_SOURCE_DIR}/${THISFILE}
  WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
  COMMAND /usr/local/bin/cpp-7
  ARGS-traditional-cpp -P ${I}.F > ${THISFILE}
  DEPENDS ${I}.F
)
LIST(APPEND FFILES ${THISFILE})
ENDFOREACH(I)

ADD_LIBRARY(flib ${FFILES})
SET_SOURCE_FILES_PROPERTIES(${FFILES} PROPERTIES GENERATED TRUE)
MESSAGE(INFO ${FFILES})


ADD_EXECUTABLE(main main.cc)
TARGET_LINK_LIBRARIES(main flib)


On 6/26/17 6:06 PM, Burlen Loring wrote:

Hi Juan,

I have faced similar challenges when calling Fortran code from C++ 
templates.


In the solution I came up with, I use a marked up Fortran template code 
and Cmake's configure_file command to generate a module for each 
combination of C++ types I need. The markup uses a token for each 
template argument and a decorator that is appended to Fortran symbols 
and is used in the module and file names to differentiate all of the 
CMake generated instantiations.


here is the relevant Cmake code that does all the work, (note: I have 
two template arguments one for coordinates and variables):


set(teca_alg_f90_srcs)

set(teca_alg_f90_generics
 gfdl_spline
 gfdl_tc_candidates
 )

set(f_type real)
set(c_types float double)
foreach(generic_src ${teca_alg_f90_generics})
 foreach(c_type_var ${c_types})
 set(iso_c_type_var "${f_type}(c_${c_type_var})")
 string(SUBSTRING ${c_type_var} 0 1 var_name)
 foreach(c_type_coord ${c_types})
 string(SUBSTRING ${c_type_coord} 0 1 coord_name)
 set(decorator "c${coord_name}_v${var_name}")
 set(iso_c_type_coord "${f_type}(c_${c_type_coord})")
 configure_file(${generic_src}.f90.in
${generic_src}_${decorator}.f90 @ONLY)
 list(APPEND teca_alg_f90_srcs
${generic_src}_${decorator}.f90)
 endforeach()
 endforeach()
endforeach()

add_library(teca_alg ${teca_alg_cxx_srcs} ${teca_alg_f90_srcs})

And here is a link to an example marked up Fortran template code.

https://github.com/LBL-EESA/TECA/blob/master/alg/gfdl_tc_candidates.f90.in

 From C++ I use macros to declare decorated Fortran functions and define 
C++ overloads that call them.


https://github.com/LBL-EESA/TECA/blob/master/alg/gfdl_tc_candidates.h

It's a bit of a heavy handed solution, but I think you can solve your 
problem in a similar way. I'm interested in hearing of other approaches 
that have worked.


Burlen


On 06/26/2017 01:40 PM, Juan E. Sanchez wrote:

Hi,

It seems like cmake cannot handle the case where the module name is 
the result of a macro.  I am using this approach to compile the same 
code for different floating point precision.  Any advice appreciated.  
This approach would apply to hundreds of files.


The error is:
Error copying Fortran module "concat".  Tried "CONCAT.mod" and 
"concat.mod".

make[2]: *** [CMakeFiles/flib.dir/baz.o.provides.build] Error 1
make[1]: *** [CMakeFiles/flib.dir/all] Error 2
make: *** [all] Error 2


Regards,

Juan


baz.F:
#include "fmacros.inc"

  module CONCAT(baz)
  contains
  subroutine car(t3)
  end subroutine
  end module CONCAT(baz)

foo.F:
#include "fmacros.inc"

  module CONCAT(foo)
  contains
  subroutine bar(t1, t2)
  use CONCAT(baz)
  implicit none
  REAL(kind=8) t1
  REAL(kind=DWIDTH) t2
  call baz(t2)
  end subroutine
  end module CONCAT(foo)

fmacros.inc:

#define CONCAT(a) a/**/_double
#define DWIDTH 8

main.cc:
extern "C" {
void
}

CMakeLists.txt:

PROJECT(foo)
ENABLE_LANGUAGE(CXX Fortran)

ADD_LIBRARY(flib foo.F baz.F)







--

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

[CMake] fortran module name issue

2017-06-26 Thread Juan E. Sanchez 

Hi,

It seems like cmake cannot handle the case where the module name is the 
result of a macro.  I am using this approach to compile the same code 
for different floating point precision.  Any advice appreciated.  This 
approach would apply to hundreds of files.


The error is:
Error copying Fortran module "concat".  Tried "CONCAT.mod" and "concat.mod".
make[2]: *** [CMakeFiles/flib.dir/baz.o.provides.build] Error 1
make[1]: *** [CMakeFiles/flib.dir/all] Error 2
make: *** [all] Error 2


Regards,

Juan


baz.F:
#include "fmacros.inc"

  module CONCAT(baz)
  contains
  subroutine car(t3)
  end subroutine
  end module CONCAT(baz)

foo.F:
#include "fmacros.inc"

  module CONCAT(foo)
  contains
  subroutine bar(t1, t2)
  use CONCAT(baz)
  implicit none
  REAL(kind=8) t1
  REAL(kind=DWIDTH) t2
  call baz(t2)
  end subroutine
  end module CONCAT(foo)

fmacros.inc:

#define CONCAT(a) a/**/_double
#define DWIDTH 8

main.cc:
extern "C" {
void
}

CMakeLists.txt:

PROJECT(foo)
ENABLE_LANGUAGE(CXX Fortran)

ADD_LIBRARY(flib foo.F baz.F)



--

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

[CMake] ctest test run order

2017-05-17 Thread Juan E. Sanchez 
I remember that the longest tests used to run first.  Now they seem to 
run in a random order on Windows, Mac, Linux.


Is this the expected behavior?  How can I get longest test first?

Regards,

Juan
--

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

[CMake] ctest not running longest tests first

2017-05-06 Thread Juan E. Sanchez 
In the past, I seem to remember that ctest would order the tests from 
longest to shortest, but this no longer seems to be the case.


Is there any way to get this behavior with the newest binary versions of 
ctest on Windows, Mac, and Linux?


Regards,

Juan
--

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

Re: [CMake] setting environment variable for ctest

2017-05-05 Thread Juan E. Sanchez 
It this possible to set for all tests as one line?  This would require 
changing dozens of tests.


Regards,

Juan

On 5/5/17 9:31 AM, CHEVRIER, Marc wrote:

Use the ENVIRONMENT property of your tests (see 
https://cmake.org/cmake/help/v3.7/prop_test/ENVIRONMENT.html).

On 05/05/2017, 16:29, "CMake on behalf of Juan E. Sanchez" 
<cmake-boun...@cmake.org on behalf of juan.e.sanc...@gmail.com> wrote:

Hello,

It appears that when I invoke ctest through cmake, the environment
variables I export from my bash shell are being ignored:
DYLD_INSERT_LIBRARIES
PATH

Is there a way to tell cmake to pass the user environment all the way
down to the environment for my tested application.

This is on Mac OS X (El Capitan) with the latest cmake binary download
3.8.1.

Regards,

Juan

--

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




--

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

[CMake] setting environment variable for ctest

2017-05-05 Thread Juan E. Sanchez 

Hello,

It appears that when I invoke ctest through cmake, the environment 
variables I export from my bash shell are being ignored:

DYLD_INSERT_LIBRARIES
PATH

Is there a way to tell cmake to pass the user environment all the way 
down to the environment for my tested application.


This is on Mac OS X (El Capitan) with the latest cmake binary download 
3.8.1.


Regards,

Juan

--

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

Re: [CMake] improve the CMake language?

2007-11-02 Thread Juan E. Sanchez 

On Fri, 2 Nov 2007, Brandon Van Every wrote:


On Nov 1, 2007 11:40 PM, Sanchez, Juan [EMAIL PROTECTED] wrote:


 Tcl is a simple language, and is well understood.  It has already been
ported to about every platform out there.  You don't need QT or wxWidgets,
because the Tk extensions of it already work.


Tcl's popularity is also on the wane.  I don't think hitching CMake's
post to Tcl is a good marketing idea.  I'd pick Ruby, for the regex
support.  Hey it's better 'n' Perl 6.  :-)


 Many features in the CMake language don't really work the way people
expect, or are not documented, or both.


I agree that much can be improved about the documentation.  I'd like
to note, however, that some improvements are happening in CVS right
now.  Enough to make me think that Kitware does take documentation
seriously and that strategically, documentation problems are going to
be addressed.  I've given a lot of gloom and doom about documentation,
that if the status quo is maintained, in 3 years' time CMake will
start to lose customers as other build systems catch up in technical
capability.  But I do think 3 years is the level of urgency of the
problem.  We'd all like things right this second, but open source has
its resource limitations.  Recently I suggested organizing Google
Summer Of Code projects to address such things.


 If anyone would like to fork cmake with me, I'm game.

 Features:

 Tcl frontend featuring modern dynamic language constructs and consistent
syntax.

 C pre-processor based dependency scanner

 Accurate and up to date documentation

 Focus on getting build system that works, because all of the language
constructs have already been written.

 Developers who are not hostile to ideas concerning improvements to the
language.


To make real improvements in all of those areas, you'd need a lot of
funding.  What kind of mandate do you have?  There's not much point in
saying everything's gonna be better if you don't have the labor.

Second question, if you do have serious development resources at your
disposal: what improvements in CMake would cause you to stick around
rather than going your own way?  Is a position of compromise possible?



This would be a community effort.  I don't have the resources to 
strike out on my own.  I like using cmake.  The language is kind of a 
bitter pill for people in my organization to swallow.


The most important item on my proposed feature list is the Tcl 
frontend.


Juan






Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake





Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] object file target

2007-07-30 Thread Juan E. Sanchez 

Hi Brandon,

By default, gnu make will always print the command to execute, as well 
as its output.  Typically, the command to be executed is muted by 
prefixing an @.  For example:


@echo Built target PerlLib

As for all of the other commands, apparently they used this trick:
# Suppress display of executed commands.
$(VERBOSE).SILENT:

where .SILENT is an actual command to treat every command as if it had 
an @ before it.


If VERBOSE is not defined, the .SILENT executes normally.  Otherwise 
setting it to 1 results in a target being created named


1.SILENT

which is a phony target and the .SILENT directive is never executed.

Necessarily, all of the cmake commands must suppress much of their 
output, unless the environment variable VERBOSE is defined.


Regards,

Juan

On Mon, 30 Jul 2007, Brandon Van Every wrote:


On 7/30/07, Bill Hoffman [EMAIL PROTECTED] wrote:

Brandon Van Every wrote:

On 7/30/07, Juan Sanchez [EMAIL PROTECTED] wrote:


I didn't think to look on the make man page, since almost every gnu make
system I dealt with had the verbose information by default.

Doing a man make reveals nothing about VERBOSE=1 since that is
specific to cmake,



No I'm googling and it's not specific to CMake.  Damned if I can find
documentation on it though.



Although other systems may use make VERBOSE=1, this is certainly a CMake
feature that was
put into the makefiles by the CMake developers


Shows my ignorance of Make then.  Setting VERBOSE=1 does appear to be
a common convention at any rate.  Was there some previous era where
almost everything in computerdom was done by passing environment
variables, and people didn't use command line flags so much?  Maybe
it's an anachronism, and some ancient manpage somewhere *does*
document a Make that expects to be controlled that way.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake





Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake