Bo Peng a écrit :
http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_use_CMake_to_build_LaTeX_documents.3F
Cited piece of code:
IF(LATEX_COMPILE)
ADD_CUSTOM_COMMAND(
OUTPUT ${Document_BINARY_DIR}/TDocument.dvi
DEPENDS ${Document_BINARY_DIR}/TDocument.tex
COMMAND ${LATEX_COMPILE}
ARGS ${Document_SOURCE_DIR}/TDocument.tex
)
ENDIF(LATEX_COMPILE)
IF(DVIPDF_COMPILE)
ADD_CUSTOM_COMMAND(
OUTPUT ${Document_BINARY_DIR}/TDocument.pdf
DEPENDS ${Document_BINARY_DIR}/TDocument.dvi
COMMAND ${DVIPDF_COMPILE}
ARGS ${Document_SOURCE_DIR}/TDocument.dvi
)
ENDIF(DVIPDF_COMPILE)
I have been reading about scons and cmake all morning, and I have to
admit that I tilts towards scons even more now. I have learned too
many languages and learning another one will simply confuse me more.
You see, with the above example, I do not know DVIPDF_COMPILE is a
string or bool, whether or not I can manipulate it etc.
I think the language is very much C-like so DVIPDF_COMPILE is a kind of
C-Macro, it could be anything but in this case, I think it is a string
and it is used like this:
#define DVIPDF_COMPILE "foo"
...
#ifdef DVIPDF_COMPILE
With scons,
class is class, variable is variable, and string is string .... and I
know I can use the re module to search for libboost.....
I agree that it's a good point for scons (to be python) but searching
for a library should be straight forward with CMake (or Scons), you
shouldn't have to wrtite an extension to do this task.
Another good thing about icons is that we can distribute a minimal
version of scon (called scons-local, just like the libtool files) so
we do not have to require scon. Of course, cmake has to be compiled,
but scons-local does not.
That's a strong advantage of Scons indeed.
Unless I find some essential problem with scons, I will not use cmake.
(Of course, if you can rewrite our auto* with cmake, I will cheer like
a real cheerleader. :-)
I am sure you will beat me at it and offer us a great lyx integrated
Scons support soon ;-)
Abdel.
Bo
