date:20080625

[CMake] Missing header files in Visual Studio project

2008-06-25 Thread Martin Apel


Hi all,

I am using the CMake generator for Visual Studio 2005 to generate 
multiple projects. CMake generates one project file per library, which 
is fine. When looking at a generated project inside Visual Studio the
project tree contains "Header files" and "Source files". Strange is, 
that under "Header files" only generated headers are listed, not any 
other headers, which are part of the source code. The "source files" 
entry contains all source files for this library. I create the library 
by doing something like
ADD_LIBRARY(Base SHARED EXCLUDE_FROM_ALL ${LocalSrc} ${GenCppFiles} 
${GenHFiles})


Do I have to add the normal header files in ADD_LIBRARY as well, so 
Visual Studio will list them? I would have expected CMake to 
automatically generate the list from the dependencies. What might be of 
interest as well (though I don't think it makes any difference), is that 
I explicitly set the regular expression to use for includes to

 INCLUDE_REGULAR_EXPRESSION ("\\.h$")
mainly to eliminate boost header files from the dependencies.

CMake version is 2.6.0.

Any thoughts on this are appreciated.

Regards,

Martin



Virus checked by G DATA AntiVirus
Version: AVKB 18.323 from 25.06.2008


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

Re: [CMake] Missing header files in Visual Studio project

2008-06-25 Thread Eric Noulard

2008/6/25 Martin Apel <[EMAIL PROTECTED]>:
> Hi all,
>
> I am using the CMake generator for Visual Studio 2005 to generate multiple
> projects. CMake generates one project file per library, which is fine. When
> looking at a generated project inside Visual Studio the
> project tree contains "Header files" and "Source files". Strange is, that
> under "Header files" only generated headers are listed, not any other
> headers, which are part of the source code. The "source files" entry
> contains all source files for this library. I create the library by doing
> something like
> ADD_LIBRARY(Base SHARED EXCLUDE_FROM_ALL ${LocalSrc} ${GenCppFiles}
> ${GenHFiles})
>
> Do I have to add the normal header files in ADD_LIBRARY as well, so Visual
> Studio will list them?

Yes you do have to do that.
Header file would appear if they are listed inside ADD_LIBRARY
or ADD_EXECUTABLE.

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

[CMake] Out-of-source build with QT_WRAP_UI

2008-06-25 Thread Roy van Pelt

Dear all, 

I'm trying to create the following situation, but so far I did not
manage to do so with the examples I found on the Internet.

I have:

build_linux\
  CMakeLists.txt
src
  ui
mainWindow.ui
  main.cxx
  main.h
CMakeLists.cxx

The root CMakeLists uses SUBDIR to run the CMakeLists for my Linux
build. Now I want QT_WRAP_UI to generate the necessary header and source
files. By default however it places them in the build directory?!

How can I get the generated files to be generated in the ui directory?

I include the current CMakeLists.txt for the linux build below.

Thanks in advance.

#
SET(EXECUTABLE_NAME bmrvis)

SET(SRC_DIR ../src)
SET(GUI_DIR ../src/ui)

#---
# Find Qt package library and include files.
#---
SET(DESIRED_QT_VERSION  ${VTK_DESIRED_QT_VERSION}  CACHE FILEPATH "")

FIND_PACKAGE(Qt4 REQUIRED)
IF(QT_USE_FILE)
INCLUDE(${QT_USE_FILE})
ELSE(QT_USE_FILE)
SET(QT_LIBRARIES ${QT_QT_LIBRARY})
ENDIF(QT_USE_FILE)

#---
# Build list of class files.
#---
SET(CLASSES  
  main
)

FOREACH(class ${CLASSES})
  SET(SOURCES ${SRC_DIR}/${class}.cxx ${SRC_DIR}/${class}.h)
ENDFOREACH(class)

#---
# Build list of ui files.
#---
SET(GUI_FILES
  QMainWindow
)

FOREACH(guifile ${GUI_FILES})
  SET(GUI ${GUI_DIR}/${guifile}.ui)
ENDFOREACH(guifile)

IF (QT_WRAP_UI)
  QT_WRAP_UI(bmrvis_gui_lib GUI_HEADERS GUI_SOURCES ${GUI} )
ENDIF (QT_WRAP_UI)

#---
# Specify that given list of source files is part of final library. 
#---
ADD_EXECUTABLE(${EXECUTABLE_NAME} ${SOURCES} ${GUI_SOURCES} )

#---
# Specify what other library files need to be linked with this one.
#---
TARGET_LINK_LIBRARIES(
  ${EXECUTABLE_NAME}
  vtkCommon
  vtkRendering
  ${QT_LIBRARIES}
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Generating import libs

2008-06-25 Thread Alexander.Camek

Hi all,

First of all thanks for the great tool.

I am using here cmake in combination with GNAT (Ada) under Windows and MinGW. 
The support of Ada for cmake was made by Alan W. Irwin who made my life much 
easier.

As I wrote in an earlier mail to the list I noticed that Cmake generates during 
build static and dynamic libraries. Then I was corrected by others of the list 
because the libraries interpreted as static ones were originally the import 
libraries for some dlls.

After some inspection I noticed that these import libraries are generated 
automtically by cmake. But these are only generated for the dlls which are 
written in C or C++. 

My question is how can the same behaviour made for Ada, so that the import 
libraries are also generated automatically for the dlls written in Ada? 
Explicit it could be done by adding -Wl,--out-implib. But I want to avoid to 
add this for every Ada written dll, because it is compiler dependent and maybe 
some developer forgets to add this to his CMakeLists.txt.

Thanks for any hint you can give.

Best regards

Alexander Camek



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

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

Re: [CMake] Generating import libs

2008-06-25 Thread Christian Ehrlicher

> Von: Alexande
> Hi all,
> 
> First of all thanks for the great tool.
> 
> I am using here cmake in combination with GNAT (Ada) under Windows and
> MinGW. The support of Ada for cmake was made by Alan W. Irwin who made my life
> much easier.
> 
> As I wrote in an earlier mail to the list I noticed that Cmake generates
> during build static and dynamic libraries. Then I was corrected by others of
> the list because the libraries interpreted as static ones were originally
> the import libraries for some dlls.
> 
> After some inspection I noticed that these import libraries are generated
> automtically by cmake.
Wrong - cmake does nothing here. Your linker creates the import libs as soon as 
it finds an exported function. We had this one week ago or so already.


Christian
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Generating import libs

2008-06-25 Thread Alexander.Camek

Hi Christian,

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Christian Ehrlicher
> Sent: Wednesday, June 25, 2008 2:22 PM
> To: cmake@cmake.org
> Subject: Re: [CMake] Generating import libs
> 
> > Von: Alexande
> > Hi all,
> > 
> > First of all thanks for the great tool.
> > 
> > I am using here cmake in combination with GNAT (Ada) under 
> Windows and 
> > MinGW. The support of Ada for cmake was made by Alan W. 
> Irwin who made 
> > my life much easier.
> > 
> > As I wrote in an earlier mail to the list I noticed that Cmake 
> > generates during build static and dynamic libraries. Then I was 
> > corrected by others of the list because the libraries 
> interpreted as 
> > static ones were originally the import libraries for some dlls.
> > 
> > After some inspection I noticed that these import libraries are 
> > generated automtically by cmake.
> Wrong - cmake does nothing here. Your linker creates the 
> import libs as soon as it finds an exported function. We had 
> this one week ago or so already.

Maybe I don't know exactly.

I see, then it will be here the wrong list for the discussion, why the linker 
creates the import lib for exported functions for C and C++. But not for Ada.

Thanks anyway.

Greetings

Alexander Camek 



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

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

[CMake] Semantics of CMAKE_SYSTEM_PROCESSOR

2008-06-25 Thread Andreas Pokorny

Hi there,
I am back from india, and now back into maintaining cmake for our project(s).
Today I came across a problem regarding CMAKE_SYSTEM_PROCESSOR.
As I understood platform definition files are supposed to set this value. The
documentations says here:
  On systems that support uname, this variable is set to the output of
uname -p,
  on windows it is set to the value of the environment variable
 PROCESSOR_ARCHITECTURE

But uname -p and PROCESSOR_ARCHITECTURE do not really match.
I.e. the cmake value will be x86 on windows, and i686 in linux, or maybe
i486 depending on the distribution. In cygwin uname is supported, but for
some reasons it returns unknown.

I think in most cases the user needs a coarse information like x86
x86_64 or arm. Then maybe in an additional variable the processor generation
like i686 or armv4  .. and so on.

To make it easier for people writing platform definitions, or platform aware
cmake scripts, there should be a list of common values for the
CMAKE_SYSTEM_PROCESSOR and other similar variables.

kind regards
Andreas Pokorny
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Extension proposal: CheckFortranFuinctionExists.cmake

2008-06-25 Thread Hauke Heibel


Hi there,

I started diving into the world of CMake and spend the last two days in 
trying to convert a project of mine to be working with CMake.


We are using BLAS in the project, so obviously I gave FIND_PACKAGE(BLAS) 
a shot. In the beginning it was not really working, but I found a 
workaround which I would like to discuss - maybe it will be useful for 
others as well.


So here is the scenario. I am given a machine having only access to 
static pre-compiled libraries of BLAS (in my case atlas.lib, cblas.lib 
and f77blas.lib). It would be great if the FIND_PACKAGE script would 
allow me to use these libraries even when I do not have a Fortran 
compiler at hand. Why should I need it anyways - the libs are pre-compiled.


So in the first step I managed to get FindBLAS.cmake running that far, 
that it finds the libs but as said before, it was failing due to the 
missing Fortran compiler. To resolve this final issue I did the following.


Since Fortran compiled libraries can be used from C/C++, why not simply 
create a test based on a .cpp file. I gave it a try and it seems to work:


CheckFortranFunctionExists.cmake (I cut things short here)

IF(_LANGUAGES_ MATCHES Fortran)
 #
ELSE(_LANGUAGES_ MATCHES Fortran)
 FILE(WRITE
   
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/testFortranCompiler.cpp

   "
   extern \"C\" void ${FUNCTION}();
   int main(int argc, char* argv[])
   {
 ${FUNCTION}(); // force linking
 return 0;
   }
   "
 )
 try_compile(${VARIABLE}
   ${CMAKE_BINARY_DIR}
   
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/testFortranCompiler.cpp

   CMAKE_FLAGS "${CHECK_FUNCTION_EXISTS_ADD_LIBRARIES}"
   OUTPUT_VARIABLE OUTPUT
 )
ENDIF(_LANGUAGES_ MATCHES Fortran)

Unless I did not get something seriously wrong with the idea of testing, 
the proposed method should work. If anybody is interested, I could 
create a CVS patch and submit it as a feature request to Mantis.


Regards,
Hauke

--
Tim Hauke Heibel
Computer Aided Medical Procedures (CAMP)
fon: +49 89 289 19427
fax: +49 89 289 17059

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

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

2008-06-25 Thread Alan W. Irwin


On 2008-06-25 15:15+0200 Hauke Heibel wrote:


Hi there,

I started diving into the world of CMake and spend the last two days in 
trying to convert a project of mine to be working with CMake.


We are using BLAS in the project, so obviously I gave FIND_PACKAGE(BLAS) a 
shot. In the beginning it was not really working, but I found a workaround 
which I would like to discuss - maybe it will be useful for others as well.


So here is the scenario. I am given a machine having only access to static 
pre-compiled libraries of BLAS (in my case atlas.lib, cblas.lib and 
f77blas.lib). It would be great if the FIND_PACKAGE script would allow me to 
use these libraries even when I do not have a Fortran compiler at hand. Why 
should I need it anyways - the libs are pre-compiled.


So in the first step I managed to get FindBLAS.cmake running that far, that 
it finds the libs but as said before, it was failing due to the missing 
Fortran compiler. To resolve this final issue I did the following.


Since Fortran compiled libraries can be used from C/C++, why not simply 
create a test based on a .cpp file. I gave it a try and it seems to work:


I think that assumption needs lots of qualifiers.  Did your run-time
actually give correct numerical results when linking from a C main programme
to f77blas.lib? Interfacing C/C++ and Fortran is a tricky business. There is
a project called cfortran that tries to do it for all the different Unix
variants, but it is pretty complicated because of various naming conventions
on each brand of Unix. Because of those complications, systems often have
both C and Fortran versions of BLAS installed.  For example, it appears your
system has cblas.lib which is the library I think you want to link to from
C/C++ code.

To check whether a function exists in that C library, you need to use
CheckFunctionExists instead of CheckFortranFunctionExists. Therefore, I
suggest you make a completely separate FindCBLAS.cmake that looks only for C
versions of BLAS and tests with CheckFunctionExists.  That gives the
build-system designer the option of using either FindCBLAS.cmake or
FindBLAS.cmake depending on which language variant of the library they want.
(That choice is not clear simply from the languages that are enabled since
you can have both Fortran and C enabled for a single project.)

Using the same analogy, I think we also should have a separate
FindCLAPACK.cmake to find and test the C variant of the LAPACK library.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] ctest and Visual Studio

2008-06-25 Thread Jesper Eskilson



I'm trying to add some tests to a project which is mainly built on
Windows using Visual Studio. The problem I have is how to locate the
binary used to run the test. The path to the binary depends on the
Visual Studio macro "$(ConfigurationName)", so when I run ctest I get:


$ vcbuild RUN_TESTS.vcproj
Build started: Project: RUN_TESTS, Configuration: Debug|Win32
--
-- Performing Post-Build Event...
-- Start processing tests
-- Test project H:/dev/marran/trunk/core/ide/cmakebuild/i686-pc-mswin32
--   1/  2 Testing jkc_jni   ***Failed
--   2/  2 Testing ide_generic   Could not find executable 
H:/dev/marran/trunk/core/
ide/../stage/$(ConfigurationName)/common/bin/TestIDE
-- Looked in the following places:
-- H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/TestIDE
-- 
H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/TestIDE.exe
-- 
H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/Debug/TestIDE
-- 
H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/Debug/TestIDE.exe
-- 
Debug/H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/TestIDE
-- 
Debug/H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/TestIDE.exe
-- Unable to find executable: 
H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/
TestIDE
-- 0% tests passed, 2 tests failed out of 2
-- The following tests FAILED:
--1 - jkc_jni (Failed)
--2 - ide_generic (Not Run)
-- Errors while running CTest
*** Project : error PRJ0019: A tool returned an error code from "Performing 
Post-Build Event..."


I.e. the TestIDE binary can't be found by ctest since ctest doesn't know
about $(ConfigurationName).

Is there a solution to this?

--
/Jesper


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

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

2008-06-25 Thread Bernd Schubert

On Wednesday 25 June 2008, Alan W. Irwin wrote:
> On 2008-06-25 15:15+0200 Hauke Heibel wrote:
> > Hi there,
> >
> > I started diving into the world of CMake and spend the last two days in
> > trying to convert a project of mine to be working with CMake.
> >
> > We are using BLAS in the project, so obviously I gave FIND_PACKAGE(BLAS)
> > a shot. In the beginning it was not really working, but I found a
> > workaround which I would like to discuss - maybe it will be useful for
> > others as well.
> >
> > So here is the scenario. I am given a machine having only access to
> > static pre-compiled libraries of BLAS (in my case atlas.lib, cblas.lib
> > and f77blas.lib). It would be great if the FIND_PACKAGE script would
> > allow me to use these libraries even when I do not have a Fortran
> > compiler at hand. Why should I need it anyways - the libs are
> > pre-compiled.
> >
> > So in the first step I managed to get FindBLAS.cmake running that far,
> > that it finds the libs but as said before, it was failing due to the
> > missing Fortran compiler. To resolve this final issue I did the
> > following.
> >
> > Since Fortran compiled libraries can be used from C/C++, why not simply
> > create a test based on a .cpp file. I gave it a try and it seems to work:
>
> I think that assumption needs lots of qualifiers.  Did your run-time
> actually give correct numerical results when linking from a C main
> programme to f77blas.lib? Interfacing C/C++ and Fortran is a tricky
> business. There is a project called cfortran that tries to do it for all
> the different Unix variants, but it is pretty complicated because of
> various naming conventions on each brand of Unix. Because of those
> complications, systems often have both C and Fortran versions of BLAS
> installed.  For example, it appears your system has cblas.lib which is the
> library I think you want to link to from C/C++ code.

No, it is really no problem to link fortran libraries and to call their 
functions. It is onkly a bit nasty sometimes to write the proto types of the 
blas/lapack functions, since nobody seems to have created a complete set of 
these, afaik. For real number crunching one also uses the intel/amd or goto 
libraries and there is always only one library of these, for both C and 
Fortran (afaik, these optimized libraries are also not written in fortran 
anymore, they just have this stupid interface to be compatible with fortran.
The other issue with fortran libraries is to figure out, how these have been 
compiled (additional underscores, etc).

On the other hand, cblas even has a slightly different interface than nativ 
blas, so without changing the existing code it is not suitable for linking.

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

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

2008-06-25 Thread Hauke Heibel

Bernd Schubert wrote:

On Wednesday 25 June 2008, Alan W. Irwin wrote:

I think that assumption needs lots of qualifiers. Did your run-time
actually give correct numerical results when linking from a C main
programme to f77blas.lib? Interfacing C/C++ and Fortran is a tricky
business. There is a project called cfortran that tries to do it for all
the different Unix variants, but it is pretty complicated because of
various naming conventions on each brand of Unix. Because of those
complications, systems often have both C and Fortran versions of BLAS
installed. For example, it appears your system has cblas.lib which is the
library I think you want to link to from C/C++ code.

No, it is really no problem to link fortran libraries and to call their
functions. It is onkly a bit nasty sometimes to write the proto types of the
blas/lapack functions, since nobody seems to have created a complete set of
these, afaik. For real number crunching one also uses the intel/amd or goto
libraries and there is always only one library of these, for both C and
Fortran (afaik, these optimized libraries are also not written in fortran
anymore, they just have this stupid interface to be compatible with fortran.
The other issue with fortran libraries is to figure out, how these have been
compiled (additional underscores, etc).

On the other hand, cblas even has a slightly different interface than nativ
blas, so without changing the existing code it is not suitable for linking.

From my experience a huge problem is the way in which
the libs are compiled (this refers to the underscore issue mentioned by
Bernd). This is currently not taken care of at all. In Boost's numeric
bindings this is taken care of by a special macro called FORTRAN_ID. It
is not straight forward to find out how the code has been compiled, but
it could be done by trial and error. If e.g. the linking in my example
from the previous mail fails it may be due to two reasons, either the
libs are missing or they have been compiled including a leading
underscore. Well, maybe even more flavors exist.

Regarding the compatibility, I tried out and verified quite a few of
the functions offered via CBLAS and LAPACK mainly via
http://boost-sandbox.cvs.sourceforge.net/boost-sandbox/boost-sandbox/boost/numeric/bindings/
. Unfortunately I did not build the libraries I am currently working
with myself so I can not give detailed information about how they were
built but my unit tests yielded correct results.

>From another Fortran library (Dierckx Fitpack) which I built myself
from within the Cygwin environment (g77 -fno-underscoring -mno-cygwin
-O3 -c *.f followed by lib *.o /out:fitpack.lib), I can say that, at
least in the way I build the libs, it is absolutely possible to use the
functions and get correct results. Obviously this requires some work by
the user, again because of the missing proxies. Row vs. column major
storage is from what I know also something one has to take care of.

Regarding the last comment of Bernd, regarding different interfaces of
CBLAS and native BLAS, I have no clue - but if that is true, isn't it
then dangerous to check at first for the "cblas;f77blas;atlas"
(FindBLAS.cmake lines 88-97) libraries and then for "sgemm;dgemm;blas"
(FindBLAS.cmake lines 100-107), etc. ??

Finally I want to emphasize that the effort that has been done in
creating the FindBLAS package is highly appreciated and that I am not
at all a Fortran specialist. I just have little experience with mixing
Fortran and C/C++ and so far I seem to have been lucky. There may be
(and unfortunately probably are) some issues I am not aware of.

- Hauke

--
Tim Hauke Heibel
Computer Aided Medical Procedures (CAMP)
fon: +49 89 289 19427
fax: +49 89 289 17059

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

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

2008-06-25 Thread Alan W. Irwin


On 2008-06-25 16:32+0200 Bernd Schubert wrote:


On Wednesday 25 June 2008, Alan W. Irwin wrote:

On 2008-06-25 15:15+0200 Hauke Heibel wrote:

Hi there,

I started diving into the world of CMake and spend the last two days in
trying to convert a project of mine to be working with CMake.

We are using BLAS in the project, so obviously I gave FIND_PACKAGE(BLAS)
a shot. In the beginning it was not really working, but I found a
workaround which I would like to discuss - maybe it will be useful for
others as well.

So here is the scenario. I am given a machine having only access to
static pre-compiled libraries of BLAS (in my case atlas.lib, cblas.lib
and f77blas.lib). It would be great if the FIND_PACKAGE script would
allow me to use these libraries even when I do not have a Fortran
compiler at hand. Why should I need it anyways - the libs are
pre-compiled.

So in the first step I managed to get FindBLAS.cmake running that far,
that it finds the libs but as said before, it was failing due to the
missing Fortran compiler. To resolve this final issue I did the
following.

Since Fortran compiled libraries can be used from C/C++, why not simply
create a test based on a .cpp file. I gave it a try and it seems to work:


I think that assumption needs lots of qualifiers.  Did your run-time
actually give correct numerical results when linking from a C main
programme to f77blas.lib? Interfacing C/C++ and Fortran is a tricky
business. There is a project called cfortran that tries to do it for all
the different Unix variants, but it is pretty complicated because of
various naming conventions on each brand of Unix. Because of those
complications, systems often have both C and Fortran versions of BLAS
installed.  For example, it appears your system has cblas.lib which is the
library I think you want to link to from C/C++ code.


No, it is really no problem to link fortran libraries and to call their
functions. It is onkly a bit nasty sometimes to write the proto types of the
blas/lapack functions, since nobody seems to have created a complete set of
these, afaik. For real number crunching one also uses the intel/amd or goto
libraries and there is always only one library of these, for both C and
Fortran (afaik, these optimized libraries are also not written in fortran
anymore, they just have this stupid interface to be compatible with fortran.
The other issue with fortran libraries is to figure out, how these have been
compiled (additional underscores, etc).


You have described issues which illustrate and support my point. They may be
considered fairly trivial on one fixed platform but become important if you
are trying to make a multi-platform build system.  For example, what do you
do about the underscore issue if you are testing the linking of C code with
the fortran blas library? On one platform you will have to test sgemm, on
another you will have to test sgemm_.  These cross-platform build-system
issues all disappear if you test C/C++ code against the C version of blas.



On the other hand, cblas even has a slightly different interface than nativ
blas, so without changing the existing code it is not suitable for linking.



Changing your existing code once to link to cblas may be a smaller price to
pay. If your existing C/C++ code linked to the fortran BLAS library is to
work on multiple platforms, what do you do about the cross-platform issue
involving underscores?  You will end up doing a lot of extra work to support
the platform variations that is not required if you link to the C version of
BLAS.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Semantics of CMAKE_SYSTEM_PROCESSOR

2008-06-25 Thread Alexander Neundorf

On Wednesday 25 June 2008, Andreas Pokorny wrote:
> Hi there,
> I am back from india, and now back into maintaining cmake for our
> project(s). Today I came across a problem regarding CMAKE_SYSTEM_PROCESSOR.
> As I understood platform definition files are supposed to set this value.
> The documentations says here:
>   On systems that support uname, this variable is set to the output of
> uname -p,
>   on windows it is set to the value of the environment variable
>  PROCESSOR_ARCHITECTURE
>
> But uname -p and PROCESSOR_ARCHITECTURE do not really match.
> I.e. the cmake value will be x86 on windows, and i686 in linux, or maybe
> i486 depending on the distribution. In cygwin uname is supported, but for
> some reasons it returns unknown.
>
> I think in most cases the user needs a coarse information like x86
> x86_64 or arm. Then maybe in an additional variable the processor
> generation like i686 or armv4  .. and so on.

The modules which come with cmake don't actually use it AFAIK (not sure about 
the cpack packaging files), so it shouldn't matter too much.
It can be used when cross compiling to be able to have more fine-grained 
control regarding the target platform and to be able to supply specialized 
files for it.

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

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

2008-06-25 Thread Bernd Schubert

On Wednesday 25 June 2008, Alan W. Irwin wrote:
> On 2008-06-25 16:32+0200 Bernd Schubert wrote:
> > On Wednesday 25 June 2008, Alan W. Irwin wrote:
> >> On 2008-06-25 15:15+0200 Hauke Heibel wrote:
> >>> Hi there,
> >>>
> >>> I started diving into the world of CMake and spend the last two days in
> >>> trying to convert a project of mine to be working with CMake.
> >>>
> >>> We are using BLAS in the project, so obviously I gave
> >>> FIND_PACKAGE(BLAS) a shot. In the beginning it was not really working,
> >>> but I found a workaround which I would like to discuss - maybe it will
> >>> be useful for others as well.
> >>>
> >>> So here is the scenario. I am given a machine having only access to
> >>> static pre-compiled libraries of BLAS (in my case atlas.lib, cblas.lib
> >>> and f77blas.lib). It would be great if the FIND_PACKAGE script would
> >>> allow me to use these libraries even when I do not have a Fortran
> >>> compiler at hand. Why should I need it anyways - the libs are
> >>> pre-compiled.
> >>>
> >>> So in the first step I managed to get FindBLAS.cmake running that far,
> >>> that it finds the libs but as said before, it was failing due to the
> >>> missing Fortran compiler. To resolve this final issue I did the
> >>> following.
> >>>
> >>> Since Fortran compiled libraries can be used from C/C++, why not simply
> >>> create a test based on a .cpp file. I gave it a try and it seems to
> >>> work:
> >>
> >> I think that assumption needs lots of qualifiers.  Did your run-time
> >> actually give correct numerical results when linking from a C main
> >> programme to f77blas.lib? Interfacing C/C++ and Fortran is a tricky
> >> business. There is a project called cfortran that tries to do it for all
> >> the different Unix variants, but it is pretty complicated because of
> >> various naming conventions on each brand of Unix. Because of those
> >> complications, systems often have both C and Fortran versions of BLAS
> >> installed.  For example, it appears your system has cblas.lib which is
> >> the library I think you want to link to from C/C++ code.
> >
> > No, it is really no problem to link fortran libraries and to call their
> > functions. It is onkly a bit nasty sometimes to write the proto types of
> > the blas/lapack functions, since nobody seems to have created a complete
> > set of these, afaik. For real number crunching one also uses the
> > intel/amd or goto libraries and there is always only one library of
> > these, for both C and Fortran (afaik, these optimized libraries are also
> > not written in fortran anymore, they just have this stupid interface to
> > be compatible with fortran. The other issue with fortran libraries is to
> > figure out, how these have been compiled (additional underscores, etc).
>
> You have described issues which illustrate and support my point. They may
> be considered fairly trivial on one fixed platform but become important if
> you are trying to make a multi-platform build system.  For example, what do
> you do about the underscore issue if you are testing the linking of C code
> with the fortran blas library? On one platform you will have to test sgemm,
> on another you will have to test sgemm_.  These cross-platform build-system
> issues all disappear if you test C/C++ code against the C version of blas.

Yeah, I entirely understand your point. Unfortunately using cblas is presently 
too troublesome. Fortunately I don't have the platform problems. All systems 
I have to deal with are Linux only.

>
> > On the other hand, cblas even has a slightly different interface than
> > nativ blas, so without changing the existing code it is not suitable for
> > linking.
>
> Changing your existing code once to link to cblas may be a smaller price to
> pay. If your existing C/C++ code linked to the fortran BLAS library is to
> work on multiple platforms, what do you do about the cross-platform issue
> involving underscores?  You will end up doing a lot of extra work to
> support the platform variations that is not required if you link to the C
> version of BLAS.

I wish it would be that easy, but for example the ACML is presently not easily 
cblas compatible (and most system I do calculations on are amd-based). 
http://forums.amd.com/forum/messageview.cfm?catid=217&threadid=89362


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

[CMake] CMake generates different outputs on different Linux machines

2008-06-25 Thread Ravi Tej Kavalipati

Hi,

I have CMakeLists.txt file which I have run on my personal linux machine and
workstation, Celertias. I get different outputs, on my personal machine I
get the executables linked to the boost libraries and on celeritas i get
those libraries NOT FOUND.

ON the Problem machine even though the boost libraries and such have been
installed in globally addressable space /usr/local/{lib,include} and
/usr/{lib,include}

The CMakeLists.txt line :
find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph regex
serialization thread system signals)

doesnt find the corresponding libraries on celeritas(problem machine) that
it does on my linux box..
I dont understand this inconsistency

I m providing the CMakeCache.txt files on both my machine and on Celeritas.

any help???
__
#CMakeLists.txt
project (hpx)

# We need to use Boost
find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph regex
serialization thread system signals)

# We need to include the hpx directory for includes
include_directories (${hpx_SOURCE_DIR})
include_directories (${hpx_SOURCE_DIR}/external/coroutine)
include_directories (${hpx_SOURCE_DIR}/external/exception)
include_directories (${hpx_SOURCE_DIR}/external/endian)
include_directories (${hpx_SOURCE_DIR}/external/logging)
include_directories (${hpx_SOURCE_DIR}/external/singleton)

if(WIN32)
add_definitions(-D_WIN32_WINNT=0x0501)
add_definitions(-D_SCL_SECURE_NO_WARNINGS)
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
add_definitions(-D_SCL_SECURE_NO_DEPRECATE)
add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
endif(WIN32)

add_subdirectory (src)
add_subdirectory (examples)
add_subdirectory (runtime)
*
***
*Working CMake Cache on my linux box:
***

Standard cmake 2.6 installation from source in /usr/local/
Standard boost 1.35.0 installed from source in /usr/local/
CMake makefile generation messages :
[EMAIL PROTECTED]:~/parallex/trunk/hpx$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found The Following Boost Libraries:
--   date_time
--   filesystem
--   graph
--   regex
--   serialization
--   thread
--   system
--   signals
-- Boost Version: 1.35.0
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cdekate/parallex/trunk/hpx
[EMAIL PROTECTED]:~/parallex/trunk/hpx$

Corresponding CMakeCache file :
http://www.cct.lsu.edu/~cdekate/Working_CMakeCache.txt

**
*Celeritas (Problem Machine)
***
*
* Standard cmake 2.6 installation from source in /usr/local/
Standard boost 1.35.0 installed from source in /usr/local/
[EMAIL PROTECTED] hpx]$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc
-- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c++
-- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cdekate/hpx
[EMAIL PROTECTED] hpx]$

Corresponding CMakeCache file:
http://www.cct.lsu.edu/~cdekate/Problem_CMakeCache.txt



Regards,
Ravi Tej
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake generates different outputs on different Linux machines

2008-06-25 Thread Mike Jackson

what would be more useful would be the file name of the boost  
date_time (for example) library on both the personal and the  
workstation. The FindBoost looks for a pretty particular filename for  
the boost libraries.


--
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Jun 25, 2008, at 3:23 PM, Ravi Tej Kavalipati wrote:


Hi,

I have CMakeLists.txt file which I have run on my personal linux  
machine and workstation, Celertias. I get different outputs, on my  
personal machine I get the executables linked to the boost  
libraries and on celeritas i get those libraries NOT FOUND.


ON the Problem machine even though the boost libraries and such  
have been installed in globally addressable space /usr/local/ 
{lib,include} and /usr/{lib,include}


The CMakeLists.txt line :
find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph  
regex serialization thread system signals)


doesnt find the corresponding libraries on celeritas(problem  
machine) that it does on my linux box..

I dont understand this inconsistency

I m providing the CMakeCache.txt files on both my machine and on  
Celeritas.


any help???
__
#CMakeLists.txt
project (hpx)

# We need to use Boost
find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph  
regex serialization thread system signals)


# We need to include the hpx directory for includes
include_directories (${hpx_SOURCE_DIR})
include_directories (${hpx_SOURCE_DIR}/external/coroutine)
include_directories (${hpx_SOURCE_DIR}/external/exception)
include_directories (${hpx_SOURCE_DIR}/external/endian)
include_directories (${hpx_SOURCE_DIR}/external/logging)
include_directories (${hpx_SOURCE_DIR}/external/singleton)

if(WIN32)
add_definitions(-D_WIN32_WINNT=0x0501)
add_definitions(-D_SCL_SECURE_NO_WARNINGS)
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
add_definitions(-D_SCL_SECURE_NO_DEPRECATE)
add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
endif(WIN32)

add_subdirectory (src)
add_subdirectory (examples)
add_subdirectory (runtime)

**
Working CMake Cache on my linux box:
**

Standard cmake 2.6 installation from source in /usr/local/
Standard boost 1.35.0 installed from source in /usr/local/
CMake makefile generation messages :
[EMAIL PROTECTED]:~/parallex/trunk/hpx$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found The Following Boost Libraries:
--   date_time
--   filesystem
--   graph
--   regex
--   serialization
--   thread
--   system
--   signals
-- Boost Version: 1.35.0
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cdekate/parallex/trunk
/hpx
[EMAIL PROTECTED]:~/parallex/trunk/hpx$

Corresponding CMakeCache file :
http://www.cct.lsu.edu/~cdekate/Working_CMakeCache.txt

**
Celeritas (Problem Machine)
**

Standard cmake 2.6 installation from source in /usr/local/
Standard boost 1.35.0 installed from source in /usr/local/
[EMAIL PROTECTED] hpx]$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc
-- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc  
-- works

-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c++
-- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c++  
-- works

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cdekate/hpx
[EMAIL PROTECTED] hpx]$

Corresponding CMakeCache file:
http://www.cct.lsu.edu/~cdekate/Problem_CMakeCache.txt



Regards,
Ravi Tej

___
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

Re: [CMake] CMake generates different outputs on different Linux machines

2008-06-25 Thread Ravi Tej Kavalipati

Library File Name Listing on Problem Machine :

http://www.cct.lsu.edu/~cdekate/problem_boost_library_list.txt

Library File Name Listing on Working Machine :

http://www.cct.lsu.edu/~cdekate/working_boost_library_list.txt


On Wed, Jun 25, 2008 at 2:23 PM, Ravi Tej Kavalipati <
[EMAIL PROTECTED]> wrote:

> Hi,
>
> I have CMakeLists.txt file which I have run on my personal linux machine
> and workstation, Celertias. I get different outputs, on my personal machine
> I get the executables linked to the boost libraries and on celeritas i get
> those libraries NOT FOUND.
>
> ON the Problem machine even though the boost libraries and such have been
> installed in globally addressable space /usr/local/{lib,include} and
> /usr/{lib,include}
>
> The CMakeLists.txt line :
> find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph regex
> serialization thread system signals)
>
> doesnt find the corresponding libraries on celeritas(problem machine) that
> it does on my linux box..
> I dont understand this inconsistency
>
> I m providing the CMakeCache.txt files on both my machine and on Celeritas.
>
> any help???
> __
> #CMakeLists.txt
> project (hpx)
>
> # We need to use Boost
> find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph regex
> serialization thread system signals)
>
> # We need to include the hpx directory for includes
> include_directories (${hpx_SOURCE_DIR})
> include_directories (${hpx_SOURCE_DIR}/external/coroutine)
> include_directories (${hpx_SOURCE_DIR}/external/exception)
> include_directories (${hpx_SOURCE_DIR}/external/endian)
> include_directories (${hpx_SOURCE_DIR}/external/logging)
> include_directories (${hpx_SOURCE_DIR}/external/singleton)
>
> if(WIN32)
> add_definitions(-D_WIN32_WINNT=0x0501)
> add_definitions(-D_SCL_SECURE_NO_WARNINGS)
> add_definitions(-D_CRT_SECURE_NO_WARNINGS)
> add_definitions(-D_SCL_SECURE_NO_DEPRECATE)
> add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
> endif(WIN32)
>
> add_subdirectory (src)
> add_subdirectory (examples)
> add_subdirectory (runtime)
> *
> ***
> *Working CMake Cache on my linux box:
> ***
>
> Standard cmake 2.6 installation from source in /usr/local/
> Standard boost 1.35.0 installed from source in /usr/local/
> CMake makefile generation messages :
> [EMAIL PROTECTED]:~/parallex/trunk/hpx$ cmake .
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Found The Following Boost Libraries:
> --   date_time
> --   filesystem
> --   graph
> --   regex
> --   serialization
> --   thread
> --   system
> --   signals
> -- Boost Version: 1.35.0
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/cdekate/parallex/trunk/hpx
> [EMAIL PROTECTED]:~/parallex/trunk/hpx$
>
> Corresponding CMakeCache file :
> http://www.cct.lsu.edu/~cdekate/Working_CMakeCache.txt
>
> **
> *Celeritas (Problem Machine)
> ***
> *
> * Standard cmake 2.6 installation from source in /usr/local/
> Standard boost 1.35.0 installed from source in /usr/local/
> [EMAIL PROTECTED] hpx]$ cmake .
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc
> -- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c++
> -- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c++ --
> works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/cdekate/hpx
> [EMAIL PROTECTED] hpx]$
>
> Corresponding CMakeCache file:
> http://www.cct.lsu.edu/~cdekate/Problem_CMakeCache.txt
>
>
>
> Regards,
> Ravi Tej
>
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake generates different outputs on different Linux machines

2008-06-25 Thread Mike Jackson

Well all that looks correct. Is GCC the same version on each machine?  
Is CMake the same version on each machine?

--
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Jun 25, 2008, at 3:46 PM, Ravi Tej Kavalipati wrote:


Library File Name Listing on Problem Machine :

http://www.cct.lsu.edu/~cdekate/problem_boost_library_list.txt

Library File Name Listing on Working Machine :

http://www.cct.lsu.edu/~cdekate/working_boost_library_list.txt


On Wed, Jun 25, 2008 at 2:23 PM, Ravi Tej Kavalipati  
<[EMAIL PROTECTED]> wrote:

Hi,

I have CMakeLists.txt file which I have run on my personal linux  
machine and workstation, Celertias. I get different outputs, on my  
personal machine I get the executables linked to the boost  
libraries and on celeritas i get those libraries NOT FOUND.


ON the Problem machine even though the boost libraries and such  
have been installed in globally addressable space /usr/local/ 
{lib,include} and /usr/{lib,include}


The CMakeLists.txt line :
find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph  
regex serialization thread system signals)


doesnt find the corresponding libraries on celeritas(problem  
machine) that it does on my linux box..

I dont understand this inconsistency

I m providing the CMakeCache.txt files on both my machine and on  
Celeritas.


any help???
__
#CMakeLists.txt
project (hpx)

# We need to use Boost
find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph  
regex serialization thread system signals)


# We need to include the hpx directory for includes
include_directories (${hpx_SOURCE_DIR})
include_directories (${hpx_SOURCE_DIR}/external/coroutine)
include_directories (${hpx_SOURCE_DIR}/external/exception)
include_directories (${hpx_SOURCE_DIR}/external/endian)
include_directories (${hpx_SOURCE_DIR}/external/logging)
include_directories (${hpx_SOURCE_DIR}/external/singleton)

if(WIN32)
add_definitions(-D_WIN32_WINNT=0x0501)
add_definitions(-D_SCL_SECURE_NO_WARNINGS)
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
add_definitions(-D_SCL_SECURE_NO_DEPRECATE)
add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
endif(WIN32)

add_subdirectory (src)
add_subdirectory (examples)
add_subdirectory (runtime)

**
Working CMake Cache on my linux box:
**

Standard cmake 2.6 installation from source in /usr/local/
Standard boost 1.35.0 installed from source in /usr/local/
CMake makefile generation messages :
[EMAIL PROTECTED]:~/parallex/trunk/hpx$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found The Following Boost Libraries:
--   date_time
--   filesystem
--   graph
--   regex
--   serialization
--   thread
--   system
--   signals
-- Boost Version: 1.35.0
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cdekate/parallex/trunk
/hpx
[EMAIL PROTECTED]:~/parallex/trunk/hpx$

Corresponding CMakeCache file :
http://www.cct.lsu.edu/~cdekate/Working_CMakeCache.txt

**
Celeritas (Problem Machine)
**

Standard cmake 2.6 installation from source in /usr/local/
Standard boost 1.35.0 installed from source in /usr/local/
[EMAIL PROTECTED] hpx]$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc
-- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc  
-- works

-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c++
-- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c++  
-- works

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cdekate/hpx
[EMAIL PROTECTED] hpx]$

Corresponding CMakeCache file:
http://www.cct.lsu.edu/~cdekate/Problem_CMakeCache.txt



Regards,
Ravi Tej


___
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

Re: [CMake] CMake generates different outputs on different Linux machines

2008-06-25 Thread Mike Jackson

Maybe the issue is with the different versions of gcc. I don't have  
Cmake 2.6 to be able to look at the FindBoost.cmake file. You might  
want to find that file (/usr/local/share/cmake-2.6/Modules) and put  
some "message (STATUS "...") commands in it to try and trace through  
what is going wrong.


--
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Jun 25, 2008, at 3:55 PM, Ravi Tej Kavalipati wrote:



both have cmake 2.6, boost 1.35.0, and on problem machine  i have  
GCC 4.2.1 and GCC 4.2.3 on my linux.


Regards,
Ravi

On Wed, Jun 25, 2008 at 2:51 PM, Mike Jackson  
<[EMAIL PROTECTED]> wrote:
Well all that looks correct. Is GCC the same version on each  
machine? Is CMake the same version on each machine?


--
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Jun 25, 2008, at 3:46 PM, Ravi Tej Kavalipati wrote:


Library File Name Listing on Problem Machine :

http://www.cct.lsu.edu/~cdekate/problem_boost_library_list.txt

Library File Name Listing on Working Machine :

http://www.cct.lsu.edu/~cdekate/working_boost_library_list.txt


On Wed, Jun 25, 2008 at 2:23 PM, Ravi Tej Kavalipati  
<[EMAIL PROTECTED]> wrote:

Hi,

I have CMakeLists.txt file which I have run on my personal linux  
machine and workstation, Celertias. I get different outputs, on my  
personal machine I get the executables linked to the boost  
libraries and on celeritas i get those libraries NOT FOUND.


ON the Problem machine even though the boost libraries and such  
have been installed in globally addressable space /usr/local/ 
{lib,include} and /usr/{lib,include}


The CMakeLists.txt line :
find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph  
regex serialization thread system signals)


doesnt find the corresponding libraries on celeritas(problem  
machine) that it does on my linux box..

I dont understand this inconsistency

I m providing the CMakeCache.txt files on both my machine and on  
Celeritas.


any help???
__
#CMakeLists.txt
project (hpx)

# We need to use Boost
find_package(Boost 1.35.0 COMPONENTS date_time filesystem graph  
regex serialization thread system signals)


# We need to include the hpx directory for includes
include_directories (${hpx_SOURCE_DIR})
include_directories (${hpx_SOURCE_DIR}/external/coroutine)
include_directories (${hpx_SOURCE_DIR}/external/exception)
include_directories (${hpx_SOURCE_DIR}/external/endian)
include_directories (${hpx_SOURCE_DIR}/external/logging)
include_directories (${hpx_SOURCE_DIR}/external/singleton)

if(WIN32)
add_definitions(-D_WIN32_WINNT=0x0501)
add_definitions(-D_SCL_SECURE_NO_WARNINGS)
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
add_definitions(-D_SCL_SECURE_NO_DEPRECATE)
add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
endif(WIN32)

add_subdirectory (src)
add_subdirectory (examples)
add_subdirectory (runtime)

**
Working CMake Cache on my linux box:
**

Standard cmake 2.6 installation from source in /usr/local/
Standard boost 1.35.0 installed from source in /usr/local/
CMake makefile generation messages :
[EMAIL PROTECTED]:~/parallex/trunk/hpx$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found The Following Boost Libraries:
--   date_time
--   filesystem
--   graph
--   regex
--   serialization
--   thread
--   system
--   signals
-- Boost Version: 1.35.0
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cdekate/parallex/trunk
/hpx
[EMAIL PROTECTED]:~/parallex/trunk/hpx$

Corresponding CMakeCache file :
http://www.cct.lsu.edu/~cdekate/Working_CMakeCache.txt

**
Celeritas (Problem Machine)
**

Standard cmake 2.6 installation from source in /usr/local/
Standard boost 1.35.0 installed from source in /usr/local/
[EMAIL PROTECTED] hpx]$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc
-- Check for working C compiler: /home/packages/gcc-4.2.1/bin/gcc  
-- works

-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c++
-- Check for working CXX compiler: /home/packages/gcc-4.2.1/bin/c+ 
+ -- works

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler A

Re: [CMake] CMake generates different outputs on different Linux machines

2008-06-25 Thread Alan W. Irwin


On 2008-06-25 14:46-0500 Ravi Tej Kavalipati wrote:


Library File Name Listing on Problem Machine :

http://www.cct.lsu.edu/~cdekate/problem_boost_library_list.txt

Library File Name Listing on Working Machine :

http://www.cct.lsu.edu/~cdekate/working_boost_library_list.txt


I know little about Boost, but as a service for those with a deeper interest
in this thread here is the diff of those two files.

--- problem_boost_library_list.txt  2008-06-25 12:39:58.0 -0700
+++ working_boost_library_list.txt  2008-06-25 12:37:17.0 -0700
@@ -26,8 +26,6 @@
 libboost_date_time-gcc42-sd-1_35.a
 libboost_date_time-gcc42-sd.a
 libboost_date_time-gcc42.so
-libboost_date_time.so.1
-libboost_date_time.so.1.32.0
 libboost_filesystem-gcc42-1_35.a
 libboost_filesystem-gcc42-1_35.so
 libboost_filesystem-gcc42-1_35.so.1.35.0
@@ -56,8 +54,6 @@
 libboost_filesystem-gcc42-sd-1_35.a
 libboost_filesystem-gcc42-sd.a
 libboost_filesystem-gcc42.so
-libboost_filesystem.so.1
-libboost_filesystem.so.1.32.0
 libboost_graph-gcc42-1_35.a
 libboost_graph-gcc42-1_35.so
 libboost_graph-gcc42-1_35.so.1.35.0
@@ -86,34 +82,6 @@
 libboost_graph-gcc42-sd-1_35.a
 libboost_graph-gcc42-sd.a
 libboost_graph-gcc42.so
-libboost_iostreams-gcc42-1_35.a
-libboost_iostreams-gcc42-1_35.so
-libboost_iostreams-gcc42-1_35.so.1.35.0
-libboost_iostreams-gcc42.a
-libboost_iostreams-gcc42-d-1_35.a
-libboost_iostreams-gcc42-d-1_35.so
-libboost_iostreams-gcc42-d-1_35.so.1.35.0
-libboost_iostreams-gcc42-d.a
-libboost_iostreams-gcc42-d.so
-libboost_iostreams-gcc42-mt-1_35.a
-libboost_iostreams-gcc42-mt-1_35.so
-libboost_iostreams-gcc42-mt-1_35.so.1.35.0
-libboost_iostreams-gcc42-mt.a
-libboost_iostreams-gcc42-mt-d-1_35.a
-libboost_iostreams-gcc42-mt-d-1_35.so
-libboost_iostreams-gcc42-mt-d-1_35.so.1.35.0
-libboost_iostreams-gcc42-mt-d.a
-libboost_iostreams-gcc42-mt-d.so
-libboost_iostreams-gcc42-mt-s-1_35.a
-libboost_iostreams-gcc42-mt-s.a
-libboost_iostreams-gcc42-mt-sd-1_35.a
-libboost_iostreams-gcc42-mt-sd.a
-libboost_iostreams-gcc42-mt.so
-libboost_iostreams-gcc42-s-1_35.a
-libboost_iostreams-gcc42-s.a
-libboost_iostreams-gcc42-sd-1_35.a
-libboost_iostreams-gcc42-sd.a
-libboost_iostreams-gcc42.so
 libboost_prg_exec_monitor-gcc42-1_35.a
 libboost_prg_exec_monitor-gcc42-1_35.so
 libboost_prg_exec_monitor-gcc42-1_35.so.1.35.0
@@ -142,8 +110,6 @@
 libboost_prg_exec_monitor-gcc42-sd-1_35.a
 libboost_prg_exec_monitor-gcc42-sd.a
 libboost_prg_exec_monitor-gcc42.so
-libboost_prg_exec_monitor.so.1
-libboost_prg_exec_monitor.so.1.32.0
 libboost_program_options-gcc42-1_35.a
 libboost_program_options-gcc42-1_35.so
 libboost_program_options-gcc42-1_35.so.1.35.0
@@ -172,38 +138,6 @@
 libboost_program_options-gcc42-sd-1_35.a
 libboost_program_options-gcc42-sd.a
 libboost_program_options-gcc42.so
-libboost_program_options.so.1
-libboost_program_options.so.1.32.0
-libboost_python-gcc42-1_35.a
-libboost_python-gcc42-1_35.so
-libboost_python-gcc42-1_35.so.1.35.0
-libboost_python-gcc42.a
-libboost_python-gcc42-d-1_35.a
-libboost_python-gcc42-d-1_35.so
-libboost_python-gcc42-d-1_35.so.1.35.0
-libboost_python-gcc42-d.a
-libboost_python-gcc42-d.so
-libboost_python-gcc42-mt-1_35.a
-libboost_python-gcc42-mt-1_35.so
-libboost_python-gcc42-mt-1_35.so.1.35.0
-libboost_python-gcc42-mt.a
-libboost_python-gcc42-mt-d-1_35.a
-libboost_python-gcc42-mt-d-1_35.so
-libboost_python-gcc42-mt-d-1_35.so.1.35.0
-libboost_python-gcc42-mt-d.a
-libboost_python-gcc42-mt-d.so
-libboost_python-gcc42-mt-s-1_35.a
-libboost_python-gcc42-mt-s.a
-libboost_python-gcc42-mt-sd-1_35.a
-libboost_python-gcc42-mt-sd.a
-libboost_python-gcc42-mt.so
-libboost_python-gcc42-s-1_35.a
-libboost_python-gcc42-s.a
-libboost_python-gcc42-sd-1_35.a
-libboost_python-gcc42-sd.a
-libboost_python-gcc42.so
-libboost_python.so.1
-libboost_python.so.1.32.0
 libboost_regex-gcc42-1_35.a
 libboost_regex-gcc42-1_35.so
 libboost_regex-gcc42-1_35.so.1.35.0
@@ -232,8 +166,6 @@
 libboost_regex-gcc42-sd-1_35.a
 libboost_regex-gcc42-sd.a
 libboost_regex-gcc42.so
-libboost_regex.so.1
-libboost_regex.so.1.32.0
 libboost_serialization-gcc42-1_35.a
 libboost_serialization-gcc42-1_35.so
 libboost_serialization-gcc42-1_35.so.1.35.0
@@ -290,8 +222,6 @@
 libboost_signals-gcc42-sd-1_35.a
 libboost_signals-gcc42-sd.a
 libboost_signals-gcc42.so
-libboost_signals.so.1
-libboost_signals.so.1.32.0
 libboost_system-gcc42-1_35.a
 libboost_system-gcc42-1_35.so
 libboost_system-gcc42-1_35.so.1.35.0
@@ -336,8 +266,6 @@
 libboost_test_exec_monitor-gcc42-s.a
 libboost_test_exec_monitor-gcc42-sd-1_35.a
 libboost_test_exec_monitor-gcc42-sd.a
-libboost_test_exec_monitor.so.1
-libboost_test_exec_monitor.so.1.32.0
 libboost_thread-gcc42-mt-1_35.a
 libboost_thread-gcc42-mt-1_35.so
 libboost_thread-gcc42-mt-1_35.so.1.35.0
@@ -352,8 +280,6 @@
 libboost_thread-gcc42-mt-sd-1_35.a
 libboost_thread-gcc42-mt-sd.a
 libboost_thread-g

Re: [CMake] CMake generates different outputs on different Linux machines

2008-06-25 Thread Mike Jackson

He really needs to "see" what files FindBoost is trying to locate.  
The best way is to hack into the FindBoost.cmake file and add some  
debugging outputs and run cmake to find out exactly what  
FindBoost.cmake is really looking for.


So down around line 449, insert the following:
MESSAGE (STATUS "${Boost_LIB_PREFIX}boost_${COMPONENT}$ 
{_boost_COMPILER}${_boost_MULTITHREADED}-${_boost_ABI_TAG}-$ 
{Boost_LIB_VERSION}")
MESSAGE (STATUS "${Boost_LIB_PREFIX}boost_${COMPONENT}$ 
{_boost_COMPILER}${_boost_MULTITHREADED}${_boost_STATIC_TAG}$ 
{_boost_ABI_TAG}-${Boost_LIB_VERSION}")
MESSAGE (STATUS "${Boost_LIB_PREFIX}boost_${COMPONENT}$ 
{_boost_MULTITHREADED}-${_boost_ABI_TAG}")
MESSAGE (STATUS "${Boost_LIB_PREFIX}boost_${COMPONENT}$ 
{_boost_MULTITHREADED}${_boost_STATIC_TAG}${_boost_ABI_TAG}")
MESSAGE (STATUS "${Boost_LIB_PREFIX}boost_${COMPONENT}-$ 
{_boost_ABI_TAG}")


and then rerun cmake on your problem machine and send the output to  
the list.


--
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Jun 25, 2008, at 4:52 PM, Alan W. Irwin wrote:


On 2008-06-25 14:46-0500 Ravi Tej Kavalipati wrote:


Library File Name Listing on Problem Machine :

http://www.cct.lsu.edu/~cdekate/ 
problem_boost_library_list.txt


Library File Name Listing on Working Machine :

http://www.cct.lsu.edu/~cdekate/ 
working_boost_library_list.txt


I know little about Boost, but as a service for those with a deeper  
interest

in this thread here is the diff of those two files.

--- problem_boost_library_list.txt  2008-06-25 12:39:58.0 -0700
+++ working_boost_library_list.txt  2008-06-25 12:37:17.0 -0700
@@ -26,8 +26,6 @@
 libboost_date_time-gcc42-sd-1_35.a
 libboost_date_time-gcc42-sd.a
 libboost_date_time-gcc42.so
-libboost_date_time.so.1
-libboost_date_time.so.1.32.0
 libboost_filesystem-gcc42-1_35.a
 libboost_filesystem-gcc42-1_35.so
 libboost_filesystem-gcc42-1_35.so.1.35.0
@@ -56,8 +54,6 @@
 libboost_filesystem-gcc42-sd-1_35.a
 libboost_filesystem-gcc42-sd.a
 libboost_filesystem-gcc42.so
-libboost_filesystem.so.1
-libboost_filesystem.so.1.32.0
 libboost_graph-gcc42-1_35.a
 libboost_graph-gcc42-1_35.so
 libboost_graph-gcc42-1_35.so.1.35.0
@@ -86,34 +82,6 @@
 libboost_graph-gcc42-sd-1_35.a
 libboost_graph-gcc42-sd.a
 libboost_graph-gcc42.so
-libboost_iostreams-gcc42-1_35.a
-libboost_iostreams-gcc42-1_35.so
-libboost_iostreams-gcc42-1_35.so.1.35.0
-libboost_iostreams-gcc42.a
-libboost_iostreams-gcc42-d-1_35.a
-libboost_iostreams-gcc42-d-1_35.so
-libboost_iostreams-gcc42-d-1_35.so.1.35.0
-libboost_iostreams-gcc42-d.a
-libboost_iostreams-gcc42-d.so
-libboost_iostreams-gcc42-mt-1_35.a
-libboost_iostreams-gcc42-mt-1_35.so
-libboost_iostreams-gcc42-mt-1_35.so.1.35.0
-libboost_iostreams-gcc42-mt.a
-libboost_iostreams-gcc42-mt-d-1_35.a
-libboost_iostreams-gcc42-mt-d-1_35.so
-libboost_iostreams-gcc42-mt-d-1_35.so.1.35.0
-libboost_iostreams-gcc42-mt-d.a
-libboost_iostreams-gcc42-mt-d.so
-libboost_iostreams-gcc42-mt-s-1_35.a
-libboost_iostreams-gcc42-mt-s.a
-libboost_iostreams-gcc42-mt-sd-1_35.a
-libboost_iostreams-gcc42-mt-sd.a
-libboost_iostreams-gcc42-mt.so
-libboost_iostreams-gcc42-s-1_35.a
-libboost_iostreams-gcc42-s.a
-libboost_iostreams-gcc42-sd-1_35.a
-libboost_iostreams-gcc42-sd.a
-libboost_iostreams-gcc42.so
 libboost_prg_exec_monitor-gcc42-1_35.a
 libboost_prg_exec_monitor-gcc42-1_35.so
 libboost_prg_exec_monitor-gcc42-1_35.so.1.35.0
@@ -142,8 +110,6 @@
 libboost_prg_exec_monitor-gcc42-sd-1_35.a
 libboost_prg_exec_monitor-gcc42-sd.a
 libboost_prg_exec_monitor-gcc42.so
-libboost_prg_exec_monitor.so.1
-libboost_prg_exec_monitor.so.1.32.0
 libboost_program_options-gcc42-1_35.a
 libboost_program_options-gcc42-1_35.so
 libboost_program_options-gcc42-1_35.so.1.35.0
@@ -172,38 +138,6 @@
 libboost_program_options-gcc42-sd-1_35.a
 libboost_program_options-gcc42-sd.a
 libboost_program_options-gcc42.so
-libboost_program_options.so.1
-libboost_program_options.so.1.32.0
-libboost_python-gcc42-1_35.a
-libboost_python-gcc42-1_35.so
-libboost_python-gcc42-1_35.so.1.35.0
-libboost_python-gcc42.a
-libboost_python-gcc42-d-1_35.a
-libboost_python-gcc42-d-1_35.so
-libboost_python-gcc42-d-1_35.so.1.35.0
-libboost_python-gcc42-d.a
-libboost_python-gcc42-d.so
-libboost_python-gcc42-mt-1_35.a
-libboost_python-gcc42-mt-1_35.so
-libboost_python-gcc42-mt-1_35.so.1.35.0
-libboost_python-gcc42-mt.a
-libboost_python-gcc42-mt-d-1_35.a
-libboost_python-gcc42-mt-d-1_35.so
-libboost_python-gcc42-mt-d-1_35.so.1.35.0
-libboost_python-gcc42-mt-d.a
-libboost_python-gcc42-mt-d.so
-libboost_python-gcc42-mt-s-1_35.a
-libboost_python-gcc42-mt-s.a
-libboost_python-gcc42-mt-sd-1_35.a
-libboost_python-gcc42-mt-sd.a
-libboost_python-gcc42-mt.so
-libboost_python-gcc42-s-1_35.a
-libboost_python-gcc42-s.a
-libboost_python-gcc42-sd-1_35.a
-libboost_python-gcc42-sd.a
-libboost

Re: [CMake] Out-of-source build with QT_WRAP_UI

2008-06-25 Thread clinton


I've written comments in between...

On Wednesday 25 June 2008 2:28:17 am Roy van Pelt wrote:
> Dear all,
>
> I'm trying to create the following situation, but so far I did not
> manage to do so with the examples I found on the Internet.
>
> I have:
>
> build_linux\
>   CMakeLists.txt
> src
>   ui
> mainWindow.ui
>   main.cxx
>   main.h
> CMakeLists.cxx
>
> The root CMakeLists uses SUBDIR to run the CMakeLists for my Linux
> build. Now I want QT_WRAP_UI to generate the necessary header and source
> files. By default however it places them in the build directory?!
>
> How can I get the generated files to be generated in the ui directory?
>
> I include the current CMakeLists.txt for the linux build below.
>
> Thanks in advance.
>
> #==
>== SET(EXECUTABLE_NAME bmrvis)
>
> SET(SRC_DIR ../src)
> SET(GUI_DIR ../src/ui)
>
> #--
>- # Find Qt package library and include files.
> #--
>- SET(DESIRED_QT_VERSION  ${VTK_DESIRED_QT_VERSION}  CACHE FILEPATH "")
Why set the DESIRED_QT_VERSION?  You probably want to remove that.

>
> FIND_PACKAGE(Qt4 REQUIRED)
> IF(QT_USE_FILE)
> INCLUDE(${QT_USE_FILE})
> ELSE(QT_USE_FILE)
> SET(QT_LIBRARIES ${QT_QT_LIBRARY})

This else case doesn't make sense when using Qt4, as it always has a use file, 
and QT_QT_LIBRARY is undefined.

> ENDIF(QT_USE_FILE)
>
> #--
>- # Build list of class files.
> #--
>- SET(CLASSES
>   main
> )
>
> FOREACH(class ${CLASSES})
>   SET(SOURCES ${SRC_DIR}/${class}.cxx ${SRC_DIR}/${class}.h)
> ENDFOREACH(class)
>
> #--
>- # Build list of ui files.
> #--
>- SET(GUI_FILES
>   QMainWindow
> )
>
> FOREACH(guifile ${GUI_FILES})
>   SET(GUI ${GUI_DIR}/${guifile}.ui)
> ENDFOREACH(guifile)
>
> IF (QT_WRAP_UI)
>   QT_WRAP_UI(bmrvis_gui_lib GUI_HEADERS GUI_SOURCES ${GUI} )
> ENDIF (QT_WRAP_UI)

When using Qt4 it should instead be
QT4_WRAP_UI(GUI_HEADERS ${GUI} )

>
> #--
>- # Specify that given list of source files is part of final library.
> #--
>- ADD_EXECUTABLE(${EXECUTABLE_NAME} ${SOURCES} ${GUI_SOURCES} )

You need to add ${GUI_HEADERS} and remove ${GUI_SOURCES}

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

[CMake] Unwanted quoting of $

2008-06-25 Thread Jarl Lindrud

Hi,

 

I've run into a problem trying to pass command line parameters to Visual
C++, that contain the $ character. I'm building a C++/CLI module, and
need to reference some .NET assemblies, with the /FU compiler option.
Since Visual Studio stores the installation location of .NET in one of
its own macros,  $(FrameworkDir), I want to pass the following compiler
options verbatim to Visual Studio:

 

/FU $(FrameworkDir)/v2.0.50727/System.dll

 

But if I go

 

ADD_DEFINES( /FU $(FrameworkDir)/v2.0.50727/System.dll ),

 

, what I end up with in Visual Studio is 

 

/FU "$"(FrameworkDir)/v2.0.50727/System.dll

 

, which obviously is not going to work.

 

So what do I need to do to pass a $ character through to Visual Studio,
without the quotes? I'm using cmake 2.6.0 .

 

Thanks,

Jarl.

 

-- 
Please consider the environment before printing this e-mail. TRIM Context is 
the perfect place to store vital e-mails for future reference.

TOWER Software Web Site: http://www.towersoft.com
 
This e-mail message (and attachments) may contain information confidential to 
TOWER Software. If you are not the intended recipient you cannot use, 
distribute or copy the message or message attachments. If you are not the 
intended recipient, please notify the sender by return e-mail immediately and 
delete all copies of the message and attachments. Opinions, conclusions and 
other information in this message and attachments that do not relate to the 
official business of TOWER Software, are not given or endorsed by it.


Message  protected by MailGuard: e-mail anti-virus, anti-spam and content 
filtering.
http://www.mailguard.com.au


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

[CMake] Company wide customization

2008-06-25 Thread Nicholas Yue


Hi,

   What is the best approach to company wide customization for CMake?

   Which file is always loaded by CMake upon start up? Is there another 
approach?


   If it is some particular file(s), can I share them with different 
platform version of CMake?


Regards

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

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

2008-06-25 Thread Arjen Markus

> On 2008-06-25 16:32+0200 Bernd Schubert wrote:
>
>> No, it is really no problem to link fortran libraries and to call their
>> functions. It is onkly a bit nasty sometimes to write the proto types of
>> the
>> blas/lapack functions, since nobody seems to have created a complete set
>> of
>> these, afaik. For real number crunching one also uses the intel/amd or
>> goto
>> libraries and there is always only one library of these, for both C and
>> Fortran (afaik, these optimized libraries are also not written in
>> fortran
>> anymore, they just have this stupid interface to be compatible with
>> fortran.
>> The other issue with fortran libraries is to figure out, how these have
>> been
>> compiled (additional underscores, etc).
>
> You have described issues which illustrate and support my point. They may
> be
> considered fairly trivial on one fixed platform but become important if
> you
> are trying to make a multi-platform build system.  For example, what do
> you
> do about the underscore issue if you are testing the linking of C code
> with
> the fortran blas library? On one platform you will have to test sgemm, on
> another you will have to test sgemm_.  These cross-platform build-system
> issues all disappear if you test C/C++ code against the C version of blas.
>
>>
>> On the other hand, cblas even has a slightly different interface than
>> nativ
>> blas, so without changing the existing code it is not suitable for
>> linking.
>>
>
> Changing your existing code once to link to cblas may be a smaller price
> to
> pay. If your existing C/C++ code linked to the fortran BLAS library is to
> work on multiple platforms, what do you do about the cross-platform issue
> involving underscores?  You will end up doing a lot of extra work to
> support
> the platform variations that is not required if you link to the C version
> of
> BLAS.
>

With regards to the differences in calling and naming conventions
between Fortran and C, I recently posted a program on the comp.lang.fortran
newsgroup to solve that issue automatically, at least for the platforms
I have access to. It is part of my Ftcl project, the combination of Fortran
and Tcl - http://ftcl.sf.net. I post it below, as it may help solving the
current issue.

The idea is very simple:
Let the linker decide which version of a C routine will be called
by the Fortran program and let that version write its properties
to a header file.

Regards,

Arjen

- probe.f90 -
! probe.f90 --
! Try and identify the Fortran naming and calling convention
! - part of Ftcl
!
! Note:
! This is the Fortran part of a program  that uses a few tricks
! to determine:
! - The naming convention for the Fortran compiler (including
!   the current options that influence this convention).
!   The result will be:
!   - One of FOR_ALL_LOWER, FOR_ALL_CAPS, FOR_UNDERSCORE or
FOR_DBL_UNDERSCORE
! will be defined. These are the most common naming conventions
! - The macro IN_BETWEEN is defined or undefined so that string
!   arguments can be properly passed
! - The macro FOR_CALL is defined to capture the correct calling
!   convention vis-a-vis stack clean-up
! - The values of these macros are stored in a file "ftcl_conventions.h"
!
! If the program fails, it will need to be expanded, as that is an
! indication that this particular combination of Fortran and C
! compilers is not yet supported.
!
program probe

character(len=7) :: first  = 'Fortran'
character(len=3) :: second = 'Tcl'

call probe_c( first, second )

end program probe

- probe_c.c -
/* probe_c.c --
 * Companion to the file probe.f90. Together they form a program
 * that will write a header file with the right macros for
 * setting up the interface between Fortran and C.
 *
 */

#include 
#include 

/* probe_c --
   Plainly named version
*/

void probe_c( char *first, int len_first, char *second, int len_second ) {

FILE *outfile ;

outfile = fopen( "ftcl_conventions.h", "w" ) ;

fprintf( outfile, "#define FOR_ALL_LOWER\n" ) ;
fprintf( outfile, "#define FOR_CALL\n" ) ;

/* If hidden length argument in between, then len_first must be 7 */
if ( len_first == 7 ) {
fprintf( outfile, "#define IN_BETWEEN\n" ) ;
} else if ( (int) second == 7 ) {
fprintf( outfile, "#undef IN_BETWEEN\n" ) ;
} else {
fprintf( stderr, "Unknown expected calling convention - assuming
NOT IN_BETWEEN!\n" ) ;
fprintf( outfile, "#undef IN_BETWEEN\n" ) ;
}

fclose( outfile ) ;
}

/* PROBE_C --
   All capitals version - possibly __stdcall too
*/
#ifdef _MSC_VER
#define FOR_CALL __stdcall
#else
#define FOR_CALL
#endif

void FOR_CALL PROBE_C( char *first, int len_first, char *second, int
len_second ) {

FILE *outfile ;

outfile = fopen( "ftcl_conventions.h", "w" ) ;

fprintf( outfile, "#define FOR_ALL_CAPS\n" ) ;
#ifdef _MSC_VER
fprintf( outfile, "#define FOR_C

[CMake] Missing header files in Visual Studio project

Re: [CMake] Missing header files in Visual Studio project

[CMake] Out-of-source build with QT_WRAP_UI

[CMake] Generating import libs

Re: [CMake] Generating import libs

Re: [CMake] Generating import libs

[CMake] Semantics of CMAKE_SYSTEM_PROCESSOR

[CMake] Extension proposal: CheckFortranFuinctionExists.cmake

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

[CMake] ctest and Visual Studio

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

Re: [CMake] Semantics of CMAKE_SYSTEM_PROCESSOR

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

[CMake] CMake generates different outputs on different Linux machines

Re: [CMake] CMake generates different outputs on different Linux machines

Re: [CMake] CMake generates different outputs on different Linux machines

Re: [CMake] CMake generates different outputs on different Linux machines

Re: [CMake] CMake generates different outputs on different Linux machines

Re: [CMake] CMake generates different outputs on different Linux machines

Re: [CMake] CMake generates different outputs on different Linux machines

Re: [CMake] Out-of-source build with QT_WRAP_UI

[CMake] Unwanted quoting of $

[CMake] Company wide customization

Re: [CMake] Extension proposal: CheckFortranFuinctionExists.cmake

26 matches

Site Navigation

Mail list logo

Footer information