headers
Philip Lowman | 1 May 2008 01:50

Re: MODULE_LIBRARY targets not copied to RUNTIME_OUTPUT_DIRECTORY (on 2.6.0 RC9)

On Wed, Apr 30, 2008 at 1:00 PM, Brad King <brad.king-5opLkZggLXlBDgjK7y7TUQ@public.gmane.org> wrote:

Philip Lowman wrote:
The vast majority of the time users are going to want their plugins dumped in RUNTIME_OUTPUT_DIRECTORY anyways so LoadLibrary() just works properly.  I can understand the desire to redirect these plugins to a separate location in your build tree (i.e.a plugins directory) although I would argue if this is the desired feature, another property name should be used instead of complicating the meaning of LIBRARY_OUTPUT_DIRECTORY.  What about simply introducing a MODULE_OUTPUT_DIRECTORY that functions identically both on Windows and Linux and let the user decide.  The net effect is the same that on Windows you would want it to likely be in "bin" and in Linux likely in "lib", but the flexibility would be there to use a separate directory for plugins if it was de sired:

What I'm talking about is something like this:

ARCHIVE_OUTPUT_DIRECTORY
  static ".a" archives
  import libraries for MSVC ".lib" or MinGW ".dll.a"

LIBRARY_OUTPUT_DIRECTORY
  shared ".so" libraries generated through ADD_LIBRARY(... SHARED)

RUNTIME_OUTPUT_DIRECTORY
 shared ".dll" libraries generated through ADD_LIBRARY(... SHARED) on Windows (MSVC, MinGW)

MODULE_OUTPUT_DIRECTORY
 shared ".so" libraries generated through ADD_LIBRARY(... MODULE)
 ".dll" dynamically linked runtime files generated through ADD_LIBRARY(... MODULE) on Windows(MSVC, MinGW)

I think this is even more complicated.  It leaves the LIBRARY variable unused on windows and the MODULE variable would still have to be set differently on different platforms.  The current design is powerful enough to do what you need.  The output directories used in the build tree are not that important.  It's the install() command that matters, and that has been using this dichotomy for years.

You're right, my suggestion would complicate things.  You have a point that users can work around this issue by just manipulating LIBRARY_OUTPUT_DIRECTORY on WIN32 to be different.  Thanks for the quick response, I wasn't aware this was how it was designed when I originally posted.

--
Philip Lowman 
_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 0 comments |
headers
George Neill | 1 May 2008 06:53

Retrieving a named argument from a list

Hi All,

Below is what I have come up with to fetch named arg from a list.  Is
there a preferred or built-in way to do this I may have missed?

MACRO(GET_NAMED_ARG _key)

  LIST(APPEND STOP_KEYWORDS DEPENDS SOURCE)

  SET(${_key} FALSE)

  SET(_stop   -1)

  FOREACH(arg ${ARGN})

    IF(NOT ${${_key}})

      STRING(COMPARE EQUAL "${arg}" "${_key}" ${_key})

    ELSE(NOT ${${_key}})

      IF(${_stop} LESS 0)

        LIST(FIND STOP_KEYWORDS ${arg} _stop)

        IF(${_stop} LESS 0)

          LIST(APPEND ${_key}_ARGS ${arg})

        ELSE(${_stop} LESS 0)

          LIST(FIND STOP_KEYWORDS ${arg} _stop)

        ENDIF(${_stop} LESS 0)

      ENDIF(${_stop} LESS 0)

    ENDIF(NOT ${${_key}})

  ENDFOREACH(arg ${ARGN})

ENDMACRO(GET_NAMED_ARG _key)

An example,

SET(MY_DEPENDS
 0 1 2 3 4
)

SET(MY_SOURCES
 5 6 7 8 9
)

LIST(APPEND MY_ARGS
  DEPENDS ${MY_DEPENDS}
  SOURCE  ${MY_SOURCES}
)

GET_NAMED_ARG(DEPENDS ${MY_ARGS})

LIST(LENGTH DEPENDS_ARGS DEPENDS_ARG_COUNT)

MESSAGE(STATUS "DEPENDS_ARGS: ${DEPENDS_ARGS}  COUNT: ${DEPENDS_ARG_COUNT}")

produces

DEPENDS_ARGS: 0;1;2;3;4  COUNT: 5

TIA,
George.
Permalink | Reply | 7 comments |
headers
Leopold Palomo Avellaneda | 1 May 2008 12:21

Re: prefer static to dynamic library on linux

A Dimecres 30 Abril 2008, John Doe va escriure:
> Hello,
>
> I just started using ubuntu linux and it is a pleasure to see that
> they provide both static and shared versions of libtcl8.4.  Is there a
> way to tell cmake to prefer the static version of this library, even
> if they are in the same directory, /usr/lib.

On way to do it is to add "-static" to your CMAKE_EXE_LINKER_FLAGS. Then, the 
linker will link use the static. Be carefull because, I think that it will 
like _all_ in static.

Regards,

Leo

--

-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 2 comments |
headers
Bill Hoffman | 1 May 2008 14:05
Favicon
Gravatar

Re: prefer static to dynamic library on linux

Leopold Palomo Avellaneda wrote:
> A Dimecres 30 Abril 2008, John Doe va escriure:
>> Hello,
>>
>> I just started using ubuntu linux and it is a pleasure to see that
>> they provide both static and shared versions of libtcl8.4.  Is there a
>> way to tell cmake to prefer the static version of this library, even
>> if they are in the same directory, /usr/lib.
> 
> On way to do it is to add "-static" to your CMAKE_EXE_LINKER_FLAGS. Then, the 
> linker will link use the static. Be carefull because, I think that it will 
> like _all_ in static.
> 

In CMake 2.6 if you give the full path to the static library then CMake 
will link that library.  CMake 2.6 uses full paths to libraries and does 
not break things into -L -l.

-Bill
Permalink | Reply | 1 comment |
headers
Convey Christian J NPRI | 1 May 2008 14:20
Picon
Picon

F77 support?

I've read that CMake 2.6 gives full support for building Fortran 90, but does it handle Fortran 77 equally well?

And are there any tricks I should know about for building F77 code with CMake and g77 on Linux?

Thanks,
Christian

Christian Convey
Scientist, Naval Undersea Warfare Centers
Newport, RI
Permalink | Reply | 1 comment |
headers
Maik Beckmann | 1 May 2008 14:42

Re: F77 support?

Am Donnerstag 01 Mai 2008 14:20:20 schrieb Convey Christian J NPRI:
> I've read that CMake 2.6 gives full support for building Fortran 90, but
> does it handle Fortran 77 equally well?

Yes.

> And are there any tricks I should know about for building F77 code with
> CMake and g77 on Linux?

Just start your CMakeLists.txt with
  project(MyProjectName Fortran)
rather than just
  project(MyProjectName)

cmake-2.4 handles F77 proper too, by the way.

-- Maik
Permalink | Reply | 0 comments |
headers
Convey Christian J NPRI | 1 May 2008 15:30
Picon
Picon

Re: F77 support?

> -----Original Message-----
> From: cmake-bounces@... 
> [mailto:cmake-bounces@...] On Behalf Of Maik Beckmann
> Sent: Thursday, May 01, 2008 8:43 AM
> To: cmake@...
> Subject: Re: [CMake] F77 support?
> 
> Am Donnerstag 01 Mai 2008 14:20:20 schrieb Convey Christian J NPRI:
> > I've read that CMake 2.6 gives full support for building 
> Fortran 90, 
> > but does it handle Fortran 77 equally well?
> 
> Yes.

All I can find on the cmake.org site is Cmake 2.4-8 and earlier.  Is 2.6 even released yet?  If so, how do I get it?

(I also noticed that the bug tracker only lets me report bugs against 2.6, which is odd, since 2.4-8 seems to
be the currently released version.)

Thanks,
Christian
Permalink | Reply | 1 comment |
headers
Maik Beckmann | 1 May 2008 15:47

Re: F77 support?

Am Donnerstag 01 Mai 2008 15:30:58 schrieb Convey Christian J NPRI:
> > -----Original Message-----
> > From: cmake-bounces@...
> > [mailto:cmake-bounces@...] On Behalf Of Maik Beckmann
> > Sent: Thursday, May 01, 2008 8:43 AM
> > To: cmake@...
> > Subject: Re: [CMake] F77 support?
> >
> > Am Donnerstag 01 Mai 2008 14:20:20 schrieb Convey Christian J NPRI:
> > > I've read that CMake 2.6 gives full support for building
> >
> > Fortran 90,
> >
> > > but does it handle Fortran 77 equally well?
> >
> > Yes.
>
> All I can find on the cmake.org site is Cmake 2.4-8 and earlier.  Is 2.6
> even released yet?  If so, how do I get it?

It hasn't.  

> (I also noticed that the bug tracker only lets me report bugs against 2.6,
> which is odd, since 2.4-8 seems to be the currently released version.)

2.4.8 should have been the very last release of 2.4 .  2.6 will be released 
soon.  You can download the lasted RC of 2.6 at
  http://www.cmake.org/files/v2.6
to test it.

Best,
 -- Maik
Permalink | Reply | 0 comments |
headers
Convey Christian J NPRI | 1 May 2008 16:05
Picon
Picon

Re: F77 support?

> 2.4.8 should have been the very last release of 2.4 .  2.6 
> will be released soon.  You can download the lasted RC of 2.6 at
>   http://www.cmake.org/files/v2.6
> to test it.

I downloaded the current CVS version (cmake-2.7.20080501.zip), and that seems to fix the main problem I
was encountering (http://public.kitware.com/Bug/view.php?id=6930).

Thanks for the help.

- Christian
Permalink | Reply | 2 comments |
headers
Convey Christian J NPRI | 1 May 2008 19:04
Picon
Picon

Can't set CMAKE_Fortran_FLAGS ?

I'm using cmake version 2.7-20080501, and I'm having trouble setting CMAKE_Fortran_FLAGS.  Any
suggestions about what I'm doing wrong?

Here's my CMakeLists.txt file:

SET(CMAKE_Fortran_COMPILER "/usr/bin/f77")
SET(CMAKE_Fortran_FLAGS "-fno-backslash")
PROJECT(CASS-4.1 Fortran)
ADD_SUBDIRECTORY(bistatic)
ADD_SUBDIRECTORY(latex)

When I run cmake, and then use ccmake to inspect the cache file, I find that:
- I did successfully force the compiler to be f77 rahter than f95.
- The variable CMAKE_Fortran_FLAGS is still blank.

I get this behavior even after removing any extant CMakeCache.txt files and CMakeFiles directories.

Thanks for any suggestions.

- Christian
Permalink | Reply | 3 comments |

Gmane