[CMake] don't auto-clean generated files?

[Aaron Turner]

On Tue, Sep 8, 2009 at 10:36 AM, Alexander
Neundorf<a.neundorf-work at gmx.net> wrote:
> On Tuesday 08 September 2009, Aaron Turner wrote:
>> On Mon, Sep 7, 2009 at 1:00 PM, Alexander
>>
>> Neundorf<a.neundorf-work at gmx.net> wrote:
>> > On Monday 07 September 2009, Aaron Turner wrote:
>> >> I'm look for a way to tell cmake to not automatically remove certain
>> >> auto-generated files when the 'clean' target is invoked.
>> >>
>> >> Basically I have:
>> >>
>> >>     add_custom_command(OUTPUT tcpbridge_opts.c tcpbridge_opts.h
>> >>         COMMAND ${AUTOGEN} -L tcpedit tcpbridge_opts.def
>> >>         DEPENDS tcpbridge_opts.def
>> >>     )
>> >>
>> >> And of course, other files depend on tcpbridge_opts.[ch]
>> >>
>> >> The problem is that I don't want tcpbridge_opts.[ch] deleted when
>> >> 'make clean' is run.
>> >
>> > Why don't you want this file to be deleted ?
>>
>> Because, counter to my general rule of thumb of never committing
>> generated code, I've decided to check in some generated code.  These
>> files also need to be shipped in the source tarballs.  Long story
>> short: The templates used to generate the files is *very* particular
>> about what version of autogen is used and I find I get far too many
>> users checking out the code who have problems when they use the wrong
>> version.
>
> That's indeed what I was assuming, and for this case add_custom_target()
> should be used.
>
>> > Maybe an ADD_CUSTOM_TARGET() would be more suitable ?
>>
>> I was under the impression that the outputs of targets are always
>> deleted when 'make clean' is run... at least that's how it seems to
>> work.
>
> With ADD_CUSTOM_TARGET() no output files are specified, so they cannot be
> cleaned.
> Here's a simple example:
> $ cat ../CMakeLists.txt
> cmake_minimum_required(VERSION 2.6)
>
> add_custom_target(MakeMyFiles COMMAND touch abc )
>
> add_executable(foo main.c)
> $
>
> This gives you a custom target "MakeMyFiles", which is only executed if you
> explicitely build it. And I think that's also what you actually want.
> I would suggest to have the custom target generate the files in the build
> tree, and then you can do with them what you want. You can copy them into the
> source tree, check them into the version control system, etc.
>
> If you use add_custom_command() you will always have the rule to regenerate
> the files in your makefiles, and so your users can still get the problem
> (since the custom command would *have* to depend on the input file) if for
> whatever reason their template file got a newer date than the generated file.

Well proper dependency tracking is a good thing IMHO.  That's why I
use a build system like cmake- so I don't have to remember what files
have changed and the ripple effects of those changes.

Honestly I'm totally OK with breakage for users foolish enough to
change a timestamp on the template file- who knows, maybe they know
what they're doing.  They can always do an 'svn revert' to put things
back the way they were if it breaks.  I know I'm stupid enough to
forget regenerating the files after making a slight change. :)

Anyways, I have a working solution it seems- just not very elegant
since it's semi-global.  I'll open up a feature request to make an
equivalent CLEAN_NO_CUSTOM property for individual files.


-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin