Hi Hazen:
On 2009-06-08 11:11-0400 Hazen Babcock wrote:
> Hi Alan,
>
> Thanks for the help and suggestions! I also added:
>
> COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/plplot_pyqt.sip
> ${CMAKE_CURRENT_BINARY_DIR}/.
>
> Since this seemed like the right thing to do to get the "python config.py"
> command to work when executed in WORKING_DIRECTORY.
>
> One result of executing "python config.py" is that it generates its own
> Makefile in WORKING_DIRECTORY. This overwrites the Makefile that was
> generated by CMake. What is the best way to handle this?
Ugh. I forgot about that nameclash with the "python config.py" approach.
You should be able to work around that by creating a python_config
subdirectory at cmake time using the file(MAKE_DIRECTORY ...) command and
using that subdirectory for your working directory instead. (Note, in this
case I prefer file(MAKE_DIRECTORY...) at cmake time rather than cmake -E
make_directory at make time.) The created *.cpp files would then be in the
examples/python/pyqt4/python_config directory along with the unused Makefile
generated by "python config.py". Note, the extension module would still be
built from examples/python/pyqt4 using the intact CMake-generated Makefile
there using the generated source file names with the python_config
subdirectory prepended to the name) so I think this idea will work to get
rid of the name clash.
If there is some further problem with this approach we could always switch
to running a pure sip custom command (with sip options appropriately
configured by cmake similar to what config.py does now) to generate the
source files. I actually don't think changing to pure sip will be necessary
for now, but if that idea appeals to you we could certainly go there after
you get the current "python config.py" approach to work all the way through
to generating the extension module.
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
__________________________
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
