Alan W. Irwin | 1 Feb 18:03 2009
Picon
Picon

CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR) and cmake_policy(VERSION 2.6.0) not working correctly for 2.6.2

According to the documentation of 2.6.2, policies CMP0008 and CMP0009
were introduced after 2.6.0.  Also, according to that documentation,
cmake_policy(VERSION 2.6.0) should set those policies to OLD and warn about
that.

I use

CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)

according to the documentation that sets

cmake_policy(VERSION 2.6.0)

by default.  This documented behaviour seems quite logical and useful so
that users can use a variety of CMake versions above 2.6.0 and get the
same 2.6.0 policies.

However, I could see no such warning messages concerning policies CMP0008 and
CMP0009 even with -Wdev (and even if I use cmake_policy(VERSION 2.6.0)
explicitly).  I then investigated further with

foreach(policy RANGE 0 9)
   if(POLICY CMP000${policy})
       message(STATUS "Policy ${policy} is ON")
   else(POLICY CMP000${policy})
       message(STATUS "Policy ${policy} is OFF")
   endif(POLICY CMP000${policy})
endforeach(policy RANGE 0 9)

and obtained
(Continue reading)

Alan W. Irwin | 1 Feb 18:50 2009
Picon
Picon

Re: CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR) and cmake_policy(VERSION 2.6.0) not working correctly for 2.6.2

On 2009-02-01 09:03-0800 Alan W. Irwin wrote:

> According to the documentation of 2.6.2, policies CMP0008 and CMP0009
> were introduced after 2.6.0.  Also, according to that documentation,
> cmake_policy(VERSION 2.6.0) should set those policies to OLD and warn about
> that.
>
> I use
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
>
> according to the documentation that sets
>
> cmake_policy(VERSION 2.6.0)
>
> by default.  This documented behaviour seems quite logical and useful so
> that users can use a variety of CMake versions above 2.6.0 and get the
> same 2.6.0 policies.
>
> However, I could see no such warning messages concerning policies CMP0008 and
> CMP0009 even with -Wdev (and even if I use cmake_policy(VERSION 2.6.0)
> explicitly).  I then investigated further with
>
> foreach(policy RANGE 0 9)
>  if(POLICY CMP000${policy})
>      message(STATUS "Policy ${policy} is ON")
>  else(POLICY CMP000${policy})
>      message(STATUS "Policy ${policy} is OFF")
>  endif(POLICY CMP000${policy})
> endforeach(policy RANGE 0 9)
(Continue reading)

Bartlett, Roscoe A | 1 Feb 23:45 2009
Picon

Re: How to append arbitrary linker options?

Setting set_target_properties(foo PROPERTIES LINK_FLAGS ...)  does not work.  The other libraries just come after these flags.
 
- Ross

From: philiplowman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org [mailto:philiplowman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] On Behalf Of Philip Lowman
Sent: Friday, January 30, 2009 11:25 AM
To: Bartlett, Roscoe A
Cc: cmake-wChDC6UyXvPYtjvyW6yDsg@public.gmane.org; Perschbacher, Brent M
Subject: Re: [CMake] How to append arbitrary linker options?

On Fri, Jan 30, 2009 at 12:56 PM, Bartlett, Roscoe A <rabartl-4OHPYypu0djtX7QSmKvirg@public.gmane.org> wrote:
Hello,
 
I would like to be able to append arbitrary linker options to the end of my link lines on Unix/Linux systems.  However, the options set in the CMAKE_EXE_LINKER_FLAGS variable are listed *before* all of the libraries that CMake knows about.  I need to be able to append a bunch of nasty options like Fortran libraries, MPI libraries (in some nasty cases) and other libraries that must come after all other libraries.
 
The problem is that while I could carefully list the libraries that need to be appended and I could use find_library(...) to get them correctly I may just have a glob of libraries and other linker options that someone gives me and I just want to apply them without having to parse everything out.
 
Is there some way to force CMake on Unix/Linux systems to append arbitrary linker options?

You can use set_target_properties(foo PROPERTIES LINK_FLAGS ...) on your targets. The LINK_FLAGS property will not contain CMAKE_EXE_LINKER_FLAGS, it's merely for special flags to be appended to linking a particular target.  If you need to apply the same linking flags to many targets you can create a function() to ease your pain. 
 
Also, be aware if you set the LINK_FLAGS property twice, the second call will overwrite the first. If you need to append to LINK_FLAGS (lets say you want one function to add fortran linking options and the other for MPI) you must first use get_target_property() and check to see if the property existed, and then append to it.

function(add_my_mpi_ldflags _target)
    if(CMAKE_COMPILER_IS_GNUCC)
        set(new_link_flags "-Whatever")
        get_target_property(existing_link_flags ${_target} LINK_FLAGS)
        if(existing_link_flags)
            set(new_link_flags "${existing_link_flags} ${new_link_flags}")
        endif()
        set_target_properties(${_target} PROPERTIES LINK_FLAGS ${new_link_flags})
    endif()
endfunction()

add_executable(foo foo.cc)
add_my_mpi_ldflags(foo)

--
Philip Lowman
_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Philip Lowman | 2 Feb 03:54 2009

Re: How to append arbitrary linker options?

On Sun, Feb 1, 2009 at 5:45 PM, Bartlett, Roscoe A <rabartl <at> sandia.gov> wrote:
Setting set_target_properties(foo PROPERTIES LINK_FLAGS ...)  does not work.  The other libraries just come after these flags.

Sorry about that, I wasn't sure if it would work or not.  Did Brad's suggestion pan out?


--
Philip Lowman
_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Bartlett, Roscoe A | 2 Feb 05:05 2009
Picon

Re: How to append arbitrary linker options?

Hello Brad,

The hack:

  set(CMAKE_CXX_LINK_EXECUTABLE
   "${CMAKE_CXX_LINK_EXECUTABLE} ${NASTY_FLAGS}")

does not work because my libraries still come after these flags.

However, the second suggestion of creaking the 'last' library seems to be working.  I am a little concerned
about using:

    target_link_libraries(last ${NASTY_FLAGS})

because the documentation for target_link_libraries(...) does not seem to suggest that you can do this.  I
just says that you can list other libraries as:

    target_link_libraries(<target> [lib1 [lib2 [...]]]
                          [[debug|optimized|general] <lib>] ...)

it does not suggest that you can pass in any old arbitrary link options.

Will this behavior that seems to be working be preserved and can it be officially documented?  Are there unit
tests in the CMake development test suite that protect this type of behavior?  Will this work on MS Windows
Visual Studio and with other generators?

This is somewhat of a hack but until CMake can address every issue automatically (like Fortran libraries in
mixed-language programs and appending -lm for C programs), we need to be able to append arbitrary
libraries at the end of a link line.

Thanks,

- Ross

> -----Original Message-----
> From: Brad King [mailto:brad.king@...] 
> Sent: Friday, January 30, 2009 12:43 PM
> To: Bartlett, Roscoe A
> Cc: cmake@...; Perschbacher, Brent M
> Subject: Re: [CMake] How to append arbitrary linker options?
> 
> Bartlett, Roscoe A wrote:
> > Hello,
> >  
> > I would like to be able to append arbitrary linker options 
> to the end 
> > of my link lines on Unix/Linux systems.  However, the 
> options set in 
> > the CMAKE_EXE_LINKER_FLAGS variable are listed *before* all of the 
> > libraries that CMake knows about.  I need to be able to 
> append a bunch 
> > of nasty options like Fortran libraries, MPI libraries (in 
> some nasty 
> > cases) and other libraries that must come after all other libraries.
> >  
> > The problem is that while I could carefully list the libraries that 
> > need to be appended and I could use find_library(...) to get them 
> > correctly I may just have a glob of libraries and other 
> linker options 
> > that someone gives me and I just want to apply them without 
> having to 
> > parse everything out.
> >  
> > Is there some way to force CMake on Unix/Linux systems to append 
> > arbitrary linker options?
> 
> There is currently no explicit feature for this.  You can 
> hack it for Makefile generators by writing
> 
>   set(CMAKE_CXX_LINK_EXECUTABLE
>     "${CMAKE_CXX_LINK_EXECUTABLE} ${NASTY_FLAGS}")
> 
> and similarly for the other languages.  There is no 
> equivalent for Visual Studio or Xcode though.
> 
> Another (hack) approach is to convince CMake's link 
> dependency analysis to put your flags at the end using a 
> helper target:
> 
>   add_library(last STATIC dummy.c)
>   target_link_libraries(last ${NASTY_FLAGS})
>   # ... link every target to 'last'
>   add_library(mylib ...)
>   target_link_libraries(mylib last)
> 
> This will guarantee that 'last' comes after all other targets 
> on link lines and that ${NASTY_FLAGS} comes after that.
> 
> I suggest doing the work to find the libraries and specify 
> them properly.  Blindly passing flags from foo-config scripts 
> could lead to trouble, especially when using multiple such 
> flag sets.  For example, consider when foo-config returns
> 
>   -L/path/to/foo/lib -lfoo
> 
> and bar-config returns
> 
>   -L/path/to/bar/lib -lbar
> 
> but /path/to/bar/lib contains a (wrong) version of libfoo.  
> If these two sets of flags get appended in the wrong order 
> the wrong foo will be found.  On the other hand if the 
> outputs of foo-config and bar-config are parsed and used to 
> find the corresponding libraries with full paths, CMake will 
> compute a safe link line for you.
> 
> -Brad
> 
> 
> 
ankit jain | 2 Feb 09:55 2009
Picon

equivalent cmakelist for this file

hi all,
 
Can anybody tell me what should be the equivalent cmakelists file should for this makefile.
 
Makefile:
 
include Make.bootstrap
# List of descriptor files for test scripts
TEST_DESCRIPTORS = a.desc b.desc c.desc d.desc
include $(MAKEMANY)
 
here each .desc file has script like this:
For a.desc:
 
$exec_string = "./a";
 
Similarly for all desc files.
 
I am not able to write a equivalent cmake file for this so that exact output will be produced as on making the simple makefile does.
 
Regards-
ankit jain
_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Hendrik Sattler | 2 Feb 10:30 2009
Picon

Re: equivalent cmakelist for this file

ankit jain schrieb:
> Can anybody tell me what should be the equivalent cmakelists file should for
> this makefile.
> 
> Makefile:
> 
> include Make.bootstrap
> # List of descriptor files for test scripts
> TEST_DESCRIPTORS = a.desc b.desc c.desc d.desc
> include $(MAKEMANY)
> 
> here each .desc file has script like this:
> For a.desc:
> 
> $exec_string = "./a";
> 
> Similarly for all desc files.
> 
> I am not able to write a equivalent cmake file for this so that exact output
> will be produced as on making the simple makefile does.

It's not "simple" but everything is hidden in the two included makefiles

HS
ankit jain | 2 Feb 10:34 2009
Picon

Re: equivalent cmakelist for this file

Then what to do. Is something can be done using Ctest.
 
ankit

2009/2/2 Hendrik Sattler <post-azCMwr5LJFZ+Wm55xJeGF4QuADTiUCJX@public.gmane.org>
ankit jain schrieb:
> Can anybody tell me what should be the equivalent cmakelists file should for
> this makefile.
>
> Makefile:
>
> include Make.bootstrap
> # List of descriptor files for test scripts
> TEST_DESCRIPTORS = a.desc b.desc c.desc d.desc
> include $(MAKEMANY)
>
> here each .desc file has script like this:
> For a.desc:
>
> $exec_string = "./a";
>
> Similarly for all desc files.
>
> I am not able to write a equivalent cmake file for this so that exact output
> will be produced as on making the simple makefile does.

It's not "simple" but everything is hidden in the two included makefiles

HS
_______________________________________________
CMake mailing list
CMake-wChDC6UyXvPYtjvyW6yDsg@public.gmane.org
http://www.cmake.org/mailman/listinfo/cmake

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Hendrik Sattler | 2 Feb 10:37 2009
Picon

Re: equivalent cmakelist for this file

ankit jain schrieb:
> Then what to do. Is something can be done using Ctest.

We cannot guess what's in those files. Don't think about what the old
build system looks like but think about what you want to achieve.

HS
ankit jain | 2 Feb 10:41 2009
Picon

Re: equivalent cmakelist for this file

Actually my motive is to run executable that are executed through  .desc file. so how to write a cmakelist file for that.
 
 
AJ

2009/2/2 Hendrik Sattler <post-azCMwr5LJFZ+Wm55xJeGF4QuADTiUCJX@public.gmane.org>
ankit jain schrieb:
> Then what to do. Is something can be done using Ctest.

We cannot guess what's in those files. Don't think about what the old
build system looks like but think about what you want to achieve.

HS

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

Gmane