[CMake] *** No rule to make target `SET.mod.proxy'

[Russell L. Carter]

Alan W. Irwin wrote:

> Our project (PLplot) has a similar issue with cmake-2.4.3.  I think what is
> going on is the fortran 95 compiler (gfortran in our case, ifort in yours)
> generates a fortran module.  In our case that is called plplot.mod and 
> it is
> generated by the fortran compiler in the top-level build tree.  Note, that
> cmake also parses the fortran source trying to track module dependencies.
> But it gets the fortran module name wrong so in our case there is an
> incorrect dependency on plplot.mod.proxy rather than the correct 
> plplot.mod.

I had just figured this out when your mail arrived.  When cmake parses
the source code it gets a few undefined symbols correct but most of
the botches are from bona fide f77 comment lines.  This happens before
the actual ifort compilation, and ifort doesn't appear to output
any .mod files for my f77 codes.  I did notice that there was some
commentary on the mail list about parsing fortran, I'd be happy to
supply the offending lines containing the misparsed symbols.

> We work around that cmake-2.4.3 bug by making a special rule to create a
> top-level file (with arbitrary contents) called plplot.mod.proxy when our
> fortran library is built.  This satisfies the incorrect make dependency
> created by cmake.

Eeeeek!  Gross!  But it works...

Thanks very much!

Russell



> 
> To try the same workaround by hand in your case, run cmake, then "touch
> SET.mod.proxy" (in the top-level build tree) then run make.  I think you
> will find that temporarily works around the problem, and a custom build 
> rule
> will "permanently" work around it.
> 
> Of course, a better procedure than such workarounds is to find out why 
> cmake
> version 2.4.3 is generating a make dependency on modulename.mod.proxy 
> rather
> than modulename.mod, but I haven't been able to figure that out.  I haven't
> made a bug report about this because I wanted to provide a solution at the
> same time.  (cmake developers have fairly recently asked for fortran help
> because they do not use fortran in their own work.)
> 
> 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 Yorick front-end to PLplot (yplot.sf.net); the
> Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________


-- 
Russell L. Carter
Esturion, LLC
2285 Sandia Drive
Prescott, Arizona 86301
928 541-0319