<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-15"

 http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Eduard Bloch wrote:<br>

<blockquote cite="mid20060825171201.GA23023@rotes76.wohnheim.uni-kl.de"

 type="cite">

  <pre wrap=""><!---->

Okay. I made a similar thing... removed the absolute path completely so

it is now generated in CMAKE_BINARY_DIR and I added ${CMAKE_BINARY_DIR}

to the INCLUDE_DIRECTORIES of each CMakeLists.txt.

This works sufficiently, all new files can be removed by nuking the

build directory. However, running "make clean" there still does not

remove those file by itself, it only removes the executable/library

targets.

  </pre>

</blockquote>

<br>

Philosophically, you're talking about a difference between configuring

things and making things.  Things that are configured are generally not

supposed to be cleaned, either in CMake or in GNU Autotools.  A

./configure script will typically generate config.h, and this is not

nuked by "make clean" either.<br>

<br>

I am aware that the GNU Coding Standards don't allow installation

pathnames to be expanded at configuration time, only at make time.  The

Autotools actively enforce this, and their documentation mandates that

people perform path substitutions at make time, i.e. using sed in

Makefile.am.  So, there are motivations to perform substitutions at

make time, and to clean them, if only because the GNU Coding Standards

are so prevalent out there.<br>

<br>

If you want to perform substitutions at make time, you will need to

write a *.cmake script containing CONFIGURE_FILE, and wrap that script

up in an ADD_CUSTOM_COMMAND.  You'll have to pass your pathnames with

-D flags on the *.cmake script command line.  There is a bit of a

learning curve about CMake scripting here.  It is all kinda tedious,

enough so that I feel less like typing up an example, and more like

asking how important this is to you?  Would the "it's a configuration"

philosophy be plenty appropriate for your needs?<br>

<br>

One final gotcha to watch out for.  If you are supporting both

./configure and CMake builds as a legacy transition, ./configure will

just dump its config.h in your source tree.  You can solve that problem

by putting your own config.h in ${CMAKE_CURRENT_BINARY_DIR} and then

doing INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_BINARY_DIR}), so that

your config.h is picked up first.<br>

<br>

<br>

Cheers,<br>

Brandon Van Every<br>

<br>

<br>

</body>

</html>