[CMake] Fortran MinGW on Windows

Andreas Mohr andi at lisas.de
Thu Jun 13 01:54:35 EDT 2013


On Wed, Jun 12, 2013 at 10:41:24PM +0000, Leek, Jim wrote:
> 
> > You do know about /usr/share/cmake-2.8/Modules/CheckLanguage.cmake , right? ;-)
> 
> Me?  I don't know anything. :)  This is actually the first time I've seen this, so thanks for that.  

I have never used this one-of-a-bazillion-CMake-modules either :)

> Your solution probably is superior.  It usually makes more sense to just build all the libraries you can, rather than building the just the ones requested by the user.  However, a list the user chooses from is what my boss asked for, so that's what I wrote.  

Yeah, and that code does both:
determine a default setting, based on system introspection, and feeds
that into the option() that's provided for the user to customize things.
Admittedly in the case of introspection ending up false,
the user won't be able to do much with that option(),
but at least he knows that something is amiss once choosing it.
OTOH that now is a strong indicator for the usefulness of an added
message(WARNING "No Fortran language - skipping MARS lib")
in case Fortran introspection went bad.

> The only clever bit is that some of these libraries can be used internally, but can't be distributed with the source due to licensing issues.  So I have a little check to see if the library exists before allowing the user to choose it:
>  
> #optional libraries, see if dir exists, then see if user wants it.  If both yes, build it.
> if(EXISTS "${PROJECT_SOURCE_DIR}/External/MARS")
>   option (USE_MARS
>         "Build and use the MARS library." OFF)
> endif() 
> if (USE_MARS)
>   enable_language(Fortran)
>   include_directories ("${PROJECT_SOURCE_DIR}/External/MARS")
>   add_subdirectory (External/MARS) 
>   set (EXTRA_LIBS ${EXTRA_LIBS} mars)
>   add_definitions(-DHAVE_MARS)

You perhaps want to move all build activity into a CMakeLists.txt in that
directory and simply do add_subdirectory() / set(EXTRA_LIBS) here.
Reasoning (that's only one reason...):
that way the sub dir could be built standalone,
due to it offering its own self-contained CMakeLists.txt
(unless MARS is an external CMake-less library not under your control,
which it likely is - in that case it might still be useful
to have *another* directory of indirection
which *then* contains a CMakeLists.txt - under your control -
that knows specifics about how to provide the MARS library)

And perhaps have an upper-level (directory) scope be able to
trigger/influence the sub build
by providing a macro/function *there*, to be called *here*,
perhaps something like:

macro(mars_library_build _out_targets)
endmacro(mars_library_build _out_targets)

HTH,

Andreas Mohr


More information about the CMake mailing list