[CMake] determine 32 vs 64 bit linux

2011-06-22 Thread Karl Merkley

I need to install a library into a directory whose name depends on the machine 
type.   For example

if (WIN32)
  if (CMAKE_CL_64)
  set(ARCH_DIR "win32")
  else()
  set(ARCH_DIR "win64")
  endif()

elseif (UNIX)
  if ()
  set(ARCH_DIR "linux32")
  else()
 set(ARCH_DIR "linux64")
endif()

Is there a better way to do this?   The win64 version seems to work correctly.  
 What variable do I check for 32 vs 64 bit linux?

  Thanks,
Karl






___
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] FindJNI.cmake

2011-05-03 Thread Karl Merkley
FindJNI.cmake is not finding the java 1.6 installation on my Windows 7 box.
When I print out the results of ${JAVA_AWT_LIBRARY_DIRECTORIES} I get the 
reference for [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development 
Kit\1.6;JavaHome]   but it doesn't look like this registry key gets expanded to 
the registry value.   How is this expansion supposed to happen?

   Karl

---
Karl Merkley, Ph.D.

Elemental Technologies, Inc.
Computational Simulation Software, LLC
www.csimsoft.com

Office:  1-801-756-1972, ext 1





___
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] Configure Mac OS X for 32-bit

2010-05-03 Thread Karl Merkley

On May 3, 2010, at 10:11 AM, Sean McBride wrote:

> On Mon, 3 May 2010 09:59:36 -0600, Karl Merkley said:
> 
>> I just read through this entire thread and I would like to expand it a
>> little.   Regardless of platform, what is the right way to determine the
>> right build architecture?  I run on a 32 bit Linux box but I use distcc
>> which distributes the build to some 64 bit machines.I always just
>> edit the CMakeCache.txt manually and add the -m32 flag.Some of my
>> customers don't like that approach and would like to automate the
>> decision for Mac, Linux and Windows.So I need to determine whether the
>> platform that cmake runs on is 32 bit or 64 bit and then set the correct
>> flags for that platform.
> 
> For Mac anyway, the 32/64 'bitness' of the building machine is
> irrelevant.  PPC Macs can build Intel code, 32 bit Macs can build 64 bit
> code, and vice versa, and etc.
> 
> Your code needs to be written such that it 1) supports both endiannesses
> 2) understands both 32 and 64 bit pointers 3) doesn't make invalid
> assumptions about the size of int, long, void*, etc.  Only if your code
> is properly written can it be built as either 32 or 64 bit.  Then I
> guess the person doing the building also has to decide which kinds of
> machines he's building for.


The code currently builds and runs in 32 or 64 bit on Linux, Mac and Windows.   
What I would like to be able to do is to detect the build environment that the 
user starts cmake in and configure correctly for that environment.   For 
example,  if I am building on my 32-bit Linux box I want to detect that gcc 
needs the -m32 flag and have that added automatically to my build process 
without having the user specify the architecture.I'm not looking at 
supporting cross-platform builds on one system, I just want to build correctly 
on the system that the user starts the build on without any further user 
intervention.It should work the same way if I am on my older Intel MacBook 
or a 64-bit Windows system.

 -- Karl


___
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] Configure Mac OS X for 32-bit

2010-05-03 Thread Karl Merkley

On May 3, 2010, at 9:24 AM, Bill Hoffman wrote:

> On 5/3/2010 11:11 AM, Tron Thomas wrote:
>> What is the purpose for the OSX_ARCHITECTURE and
>> OSX_ARCHITECTURES_ properties that already exist in CMAKE? It
>> seems like they might be properties that are already meant to address an
>> issue like this, only I can't figure out how they work.
>> 
> OSX_ARCHITECTURES is mostly meant to select which archs you want to build. It 
> was designed with the idea that it would be selected by the end user and not 
> in the CMakeLists.txt of the project.   CMake uses this to create its fat 
> binaries (ppc/i386) on the mac.
> 
>> Also, I think previous versions of CMake did not have this problem, only
>> I'm not certain of that.
>> 
> We just verified, CMake 2.2.3 through to 2.8.1 all default to building 64 bit 
> on 10.6.  The change was by Apple not CMake.
> 
> -Bill


I just read through this entire thread and I would like to expand it a little.  
 Regardless of platform, what is the right way to determine the right build 
architecture?  I run on a 32 bit Linux box but I use distcc which distributes 
the build to some 64 bit machines.I always just edit the CMakeCache.txt 
manually and add the -m32 flag.Some of my customers don't like that 
approach and would like to automate the decision for Mac, Linux and Windows.
So I need to determine is that platform that cmake runs on 32 bit or 64 bit and 
then set the correct flags for each platform.

Any ideas?

   Karl


___
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 2.4.8 RC 9

2008-01-03 Thread Karl Merkley
I was just testing the dmg install on a Mac G5 running Mac OS X  
10.4 .   I do find it a touch odd that if I choose a directory  
($dir)  for install that it places it in $dir/usr.   This means that  
if I want to do an install into /usr/local I get a /usr/local/usr/ 
bin.   That doesn't seem quite right.I haven't tried bundling my  
own package yet.


   Karl
On Jan 2, 2008, at 10:16 AM, Mike Jackson wrote:



On Jan 2, 2008, at 10:53 AM, Bill Hoffman wrote:


Bill Hoffman wrote:
I have a new beta release for 2.4.8 ready for cmake.  This will  
be the last  release of the 2.4.X branch.  The next release will  
be 2.6.0.  So,
please make sure you test it if you are interested in a 2.4.8.   
Send any

issues to me or the cmake list.  Thanks.


Just a reminder for folks to try 2.4.8 RC 9.  I would like to  
create the final 2.4.8 very soon


-Bill



Downloaded 2.4.8 RC9 source and compiled with ICC version 9.1.040  
on OS X 10.4.11 (intel). I built RC-9 using CMake 2.4.7 if that  
matters. I have a small example project with the following layout:


 |--CMakeLists.txt
 |--src
 |foo.cxx
 |foo.h

Here is my CMakeLists.txt file:

PROJECT (TestProj)
# -- Setup output Directories -
SET (LIBRARY_OUTPUT_PATH
  ${PROJECT_BINARY_DIR}/Bin
  CACHE PATH
  "Single Directory for all Libraries"
  )
# - Setup the Executable output Directory -
SET (EXECUTABLE_OUTPUT_PATH
  ${PROJECT_BINARY_DIR}/Bin
  CACHE PATH
  "Single Directory for all Executables."
  )
INSTALL(DIRECTORY ${PROJECT_SOURCE_DIR}/src  DESTINATION include/ 
TestProj

  PATTERN "*.h"
)
#  End CMakeLists.txt ---

Running cmake and then make install yields the following output:

[EMAIL PROTECTED]:Build]$ make install
Install the project...
-- Install configuration: "Debug"
-- Installing /tmp/include/TestProj/src
-- Installing /tmp/include/TestProj/src/foo.cxx
-- Installing /tmp/include/TestProj/src/foo.h

it is my understanding that ONLY the .h file should have been  
installed. Is this a bug or just a misunderstanding of the usage of  
INSTALL command?


Thanks
--
Mike Jackson
imikejackson & gmail * com




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





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


[CMake] FindPythonLibs

2007-02-21 Thread Karl Merkley


I'm linking an app with the python library and I have a requirement  
to link with the shared library not the static library.  It appears  
that FindPythonLibs has no way of specifying shared vs. static.   The  
shared lib actually is installed in /usr/lib.  The static lib resides  
in /usr/lib/python2.4/config (which is where FindPythonLibs goes  
looking for it).   Any ideas on how to resolve this issue so that  
automatic builds don't have to have a tweak to the CMakeCache.txt?


 Karl


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


[CMake] swig and LINK_DIRECTORIES

2007-02-09 Thread Karl Merkley
I have a file that I am swigging that needs to be linked with files  
that reside someplace else on the OS.  How can I get the UseSWIG to  
look for the libraries in the correct  place?


Below is a truncated CMakeLists.txt  that approximates what I am  
trying to do.


PROJECT(nurbs)

FIND_PACKAGE(SWIG REQUIRED)
INCLUDE(${SWIG_USE_FILE})
FIND_PACKAGE(PythonLibs REQUIRED)

INCLUDE(UseACIS.cmake)

SET SOURCE_FILE_PROPERTIES(nurbs.i PROPERTIES CPLUSPLUS ON  
OBJECT_DEPENDS nurbs.hpp)

SWIG_ADD_MODULE(nurbs python nurbs.i nurbs.hpp)

LINK_DIRECTORIES( ${ACIS_LIBRARY_DIR})  #this doesn't work!

SWIG_LINK_LIBRARIES(nurbs ${PYTHON_LIBRARIES}  ${ACIS_LIBS})


Thanks,
Karl

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


Re: [CMake] ccmake and fortran

2006-08-11 Thread Karl Merkley


What I found with the module problem was that the parser was picking  
up the keyword in the comment.  I just did something like add braces  
around the module keyword so that the parser was a little more  
confused and didn't identify the word module in the comment.   
Something like . . .


c   this is a {module} in fortran

After that it worked great including the dependencies.  The fix is to  
modify the parser so that any line that has  a "c" (case independent)  
in the first line is skipped.  Unfortunately, my flex/bison skills  
are non-existent so I wouldn't have a clue as to how to make that  
change!


   Karl

On Aug 11, 2006, at 11:58 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote:

Thanks Bill that worked great!  I was missing the step about  
deleting the cache file.


The next problem that I ran into was various mod.proxy dependency  
issues.  I saw an earlier thread on this but no solution was  
reached.  I ended up commenting out the module dependency code  
under cmDependsFortran.cxx.  Everything compiled fine with that fix.


I'm not an expert at fortran modules.  My code is legacy f77 as is  
my fortran knowledge base... but I wondering  if the way that  
cmDependsFortran is adding module dependencies is specific to the  
gnu fortran compiler.  I know the intel fortran compile that I'm  
using doesn't generate any mod.proxy files.  If there are any f90  
module specific tests that I can run, I would be happy to do so  
with the intel compiler in order to investigate the problem further.


Thanks,

Bryan Walsh


 "William A. Hoffman" <[EMAIL PROTECTED]> wrote:




When I run ccmake and set CMAKE_Fortran_Compiler to ifort or $ 
{Install Path}/ifort and then configure CMAKE_Fortran_Compiler  
resets back to the gnu compiler /usr/bin/f95.  I don't understand  
why this is happening.  Any ideas?


I'm running on FC4, with CMAKE 2.4.3.  Running ifort from the  
command line works fine.



Remove the CMakeCache.txt file.

Then set the environment variable FC to ifort.   Then re-run ccmake.

Cmake looks for fortran compilers in this order:

 SET(CMAKE_Fortran_COMPILER_LIST ifort ifc efc f95 pgf95
  lf95 xlf95 fort gfortran f90  pgf90   xlf90   epcf90  
fort77 frt pgf77  xlf  fl32 af77 g77 f77  )



Are you sure that ifort is in your path when you run ccmake?
But the environment variable FC should force cmake to pick ifort.

setenv FC /path/to/ifort
or
export FC=/path/to/ifort


-Bill



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




--
Karl G. Merkley, Ph.D.
[EMAIL PROTECTED] / [EMAIL PROTECTED]
csimsoft, LLC.
17 North Merchant Street
American Fork, UT 84003

(801) 756-1972 ext 1


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


Re: [CMake] Fortran question

2006-07-31 Thread Karl Merkley


On Jul 24, 2006, at 2:15 PM, Brad King wrote:


Karl Merkley wrote:

I have a simple Fortran project that I am testing with cmake.

PROJECT(multi_patch Fortran)

SET( SRCS
   aAdjKeep.f
   Main_mp.f
  )

ADD_EXECUTABLE(multi_patch ${SRCS})

However, the first file is a Fortran 95 module and when I try to  
build I get

the following error.

Scanning dependencies of target multi_patch
Building Fortran object CMakeFiles/multi_patch.dir/aAdjKeep.o
Error copying Fortran module "for".  Tried "FOR.mod" and "for.mod".

If I just do a
   gfortran -c aAdjKeep.f
it compiles and creates aadjkeep.mod.

What is the status of the Fortran support.  Where is a good  
starting place to

look in the code base to see what is going on?


Unfortunately we don't have time to debug/fix problems with the module
support for Fortran ourselves.  Use "grep" to look for references to
fortran in the CMake/Source directory.  In particular you might  
look for

"cmake_copy_f90_mod" to see code related to this error message.

-Brad



I thought I had seen someplace where Fortran support was not high on  
the priority list.  I may not like it but I understand.


I have isolated the problem and submitted a bug on it (#3564).  The  
problem seems to be that the cmake parser finds the Fortran keyword  
module inside of a comment line.  Fixing this is probably pretty easy  
for a flex/bison guru but that is _not_ my area of expertise.  If  
someone gets a chance to look at this I would appreciate it.


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


[CMake] Fortran question

2006-07-24 Thread Karl Merkley
I have a simple Fortran project that I am testing with cmake.

PROJECT(multi_patch Fortran)

SET( SRCS
   aAdjKeep.f
   Main_mp.f
  )

ADD_EXECUTABLE(multi_patch ${SRCS})

However, the first file is a Fortran 95 module and when I try to build I get
the following error.

Scanning dependencies of target multi_patch
Building Fortran object CMakeFiles/multi_patch.dir/aAdjKeep.o
Error copying Fortran module "for".  Tried "FOR.mod" and "for.mod".

If I just do a
   gfortran -c aAdjKeep.f
it compiles and creates aadjkeep.mod.

What is the status of the Fortran support.  Where is a good starting place to
look in the code base to see what is going on?

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


[CMake] ctest setup

2006-06-19 Thread Karl Merkley
I'm trying to get a ctest script to automatically checkout, build,  
and run my test suite on Mac OS X 10.4.6.  I'm trying to develop one  
common template script that could be used on multiple platforms. 
It does the cvs checkout, runs cmake, but make never gets invoked.
Any ideas on what I'm doing wrong?


   Thanks,
Karl


SET (CTEST_SOURCE_DIRECTORY "/Users/kgmerk/projects/testing/cubitclaro")
SET (CTEST_BINARY_DIRECTORY "/Users/kgmerk/projects/testing/ 
cubitclaro/build")


# what cmake command to use for configuring this dashboard
SET (CTEST_CMAKE_COMMAND /usr/bin/cmake)

SET (CTEST_CVS_COMMAND "cvs")
SET (CTEST_CVS_CHECKOUT  "${CTEST_CMAKE_COMMAND} -E chdir /Users/ 
kgmerk/projects/testing ${CTEST_CVS_COMMAND} - 
d:pserver:[EMAIL PROTECTED]:2405/usr/local/eng_sci/CVS co cubitclaro")


# which ctest command to use for running the dashboard
SET (CTEST_COMMAND "/usr/bin/ctest -D Experimental")



# The values in this section are optional you can either
# have them or leave them commented out


# should ctest wipe the binary tree before running
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)

# this is the initial cache to use for the binary tree, be careful to  
escape

# any quotes inside of this string if you use it
SET (CTEST_INITIAL_CACHE "
MAKECOMMAND:STRING=make -i
CMAKE_MAKE_PROGRAM:FILEPATH=make
CMAKE_GENERATOR:INTERNAL=Unix Makefiles
BUILDNAME:STRING=ETI-Mac
SITE:STRING=ETI
CVSCOMMAND:FILEPATH=cvs
")

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


Re: [CMake] CPack and install_name_tool on the Mac

2006-06-16 Thread Karl Merkley


On Jun 16, 2006, at 11:47 AM, Brad King wrote:


Karl Merkley wrote:
Does CPack have any ability to help with the install_name_tool on  
the  Mac?  Mac applications avoid DLL hell by creating an  
application  bundle that is really a directory structure that  
includes the  application, the resources, and the shared libraries  
used by the  application.   My understanding is that the  
install_name_tool  essentially modifies the RPATH of the  
distributed application so that  it looks for the shared libraries  
in the bundle rather than some  random location.   I have a script  
that I run to make this all work,  but it has to be modified as  
libraries change.  Or, if I somehow  forget to run this step the  
whole distribution is bad.   Does CPack  help with this?


Look at the SET_TARGET_PROPERTIES command documentation:

  cmake --help-command SET_TARGET_PROPERTIES

In CMake 2.4 there is an INSTALL_NAME_DIR property that you can use  
to control the install_name of the installed library or executable.


-Brad


So this is actually part of the make install process then, right?
Are there any examples anywhere?   I'd even be willing to write it up  
in the wiki ;-)


 Karl

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


[CMake] CPack and install_name_tool on the Mac

2006-06-16 Thread Karl Merkley
Does CPack have any ability to help with the install_name_tool on the  
Mac?  Mac applications avoid DLL hell by creating an application  
bundle that is really a directory structure that includes the  
application, the resources, and the shared libraries used by the  
application.   My understanding is that the install_name_tool  
essentially modifies the RPATH of the distributed application so that  
it looks for the shared libraries in the bundle rather than some  
random location.   I have a script that I run to make this all work,  
but it has to be modified as libraries change.  Or, if I somehow  
forget to run this step the whole distribution is bad.   Does CPack  
help with this?


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


[CMake] case in IF statements

2006-06-15 Thread Karl Merkley
I'm playing with cmake 2.4-2.   I read recently that had been changed  
to accept lower case arguments  (if instead of IF).  However, it  
appears that modifiers within the IF statement still must be upper  
cased.  For example,  if (NOT UNIX)  appears to work but if (not  
UNIX) fails.   I noticed the same behavior with AND, MATCHES and  
STREQUAL in an IF statement.Is this by design or is it a bug?


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