Notes
(0017425) Brad King (manager) 2009-09-14 11:43	By "create_custom_target" I'll assume you mean "add_custom_target". So, you want to exclude a specific target from the default "make clean", right? Something like a per-target NO_CLEAN, perhaps: add_custom_target(mytarget ...) set_property(TARGET mytarget PROPERTY NO_CLEAN 1) Note that the CLEAN_NO_CUSTOM property only affects the Makefile generators. Visual Studio IDE projects still clean everything...and there is no way to stop them. I'm always hesitant to create generator-specific features. The only reason CLEAN_NO_CUSTOM exists is historical. What is your use case?

(0017547) Mark de Wever (reporter) 2009-09-15 16:30	I'm also interested in this feature. For the project I work on I use both add_custom_target and add_custom_command, of which I want some cleaned and some not. We use the custom targets and custom commands to generate gettext translations. This generates pot- and po-files which shouldn't be removed (they are stored in our repository) since it makes it easier to update translations when a translator sends an update. It also generates mo-files which should be cleaned when using make clean.

(0017548) Aaron Turner (reporter) 2009-09-15 16:44	My use case is: I use GNU Autogen to convert .def files into .c and .h files. Autogen is very picky though about versions though and it creates a bunch of problems for my users who check code out via SVN. My "solution" has been to include the autogen tearoff code and link against that as well as check into SVN the generated .c & .h files. This allows users to build my code regardless of what version of autogen they have installed (or if they don't have it installed at all). The problem is if they run 'make clean', these files will be deleted. yes, they can be recovered via SVN, but by default cmake will rebuild these files (likely with the wrong version of Autogen) and then the build fails in strange and spectacular ways. I've tried explaining/documenting this but of course nobody reads the docs and they end up complaining that my code is crap b/c it doesn't build. Ideally, I want these Autogen'd files only deleted via a custom_target (aka clean-autogen) and let cmake detect when the .c & .h files are out of date and regenerate them automatically. If a user edits a .def file, then hopefully they know what they're doing. Obviously, CLEAN_NO_CUSTOM will do this, but it's basically global for an entire directory which is less then ideal. Obviously I can work around this by placing these files in their own subdir so not to impact other files. Sucks that MS Visual Studio always cleans everything, but I guess I'm not surprised. In my specific case, it doesn't matter since Autogen won't build under MSVC++. Honestly, right now I don't need this feature. It was more of a request based on what I see as an limitation in the design of CLEAN_NO_CUSTOM which didn't seem optimal.

(0017556) Brad King (manager) 2009-09-16 10:11	Hmm...both use cases mentioned above involve generating files into the source directory as a convenience. In these cases "make clean" is not the only potential cause of trouble. Any time the build system thinks the files are out of date it will try to rebuild them. In synfinatic's case, a user might remove the .def file accidentally and fix it with 'svn up' which will put a new timestamp on it and the rule will run. I suggest using the option() command to enable the custom commands for these files only for users that want to edit the .def files: option(USE_AUTOGEN "Use autogen to process .def file edits." OFF) if(USE_AUTOGEN) ... find and use autogen executable in custom commands ... endif() Another approach is to find autogen and check its version and configuration. Then add the update rules only if a valid autogen is available. These solutions will work in all generators (VS, Makefiles, etc.). That said, I can see value in a NO_CLEAN property as a convenience for developers who do use make and turn on autogen rules. I'll put this on my wish-todo list and leave this feature request open in case someone supplies a patch.

(0017566) Aaron Turner (reporter) 2009-09-16 12:39	Thanks Brad. Your config option idea is something I'm going to look into as well.

(0030490) Brad King (manager) 2012-08-13 10:36	Sending issues I'm not actively working on to the backlog to await someone with time for them. If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^] It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.

(0041589) Kitware Robot (administrator) 2016-06-10 14:27	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2009-09-08 14:48	Aaron Turner	New Issue
2009-09-11 17:22	Bill Hoffman	Status	new => assigned
2009-09-11 17:22	Bill Hoffman	Assigned To	=> Brad King
2009-09-14 11:43	Brad King	Note Added: 0017425
2009-09-15 16:30	Mark de Wever	Note Added: 0017547
2009-09-15 16:44	Aaron Turner	Note Added: 0017548
2009-09-16 10:11	Brad King	Note Added: 0017556
2009-09-16 12:39	Aaron Turner	Note Added: 0017566
2012-08-13 10:36	Brad King	Status	assigned => backlog
2012-08-13 10:36	Brad King	Note Added: 0030490
2016-06-10 14:27	Kitware Robot	Note Added: 0041589
2016-06-10 14:27	Kitware Robot	Status	backlog => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:30	Kitware Robot	Status	resolved => closed

Relationships