Notes |
|
(0010901)
|
Akos Maroy
|
2008-03-25 02:47
|
|
yes, it would be very very handy & nice to have this feature.. |
|
|
(0013078)
|
Brad King
|
2008-08-19 15:23
|
|
Can anyone give me a real use case in which out-of-source builds are less desireable than in-source? What do you mean by "stuck" with in-source? |
|
|
(0013103)
|
Philip Lowman
|
2008-08-19 22:44
|
|
We have an application that comes with a bunch of configuration files packaged in the source tree. It's annoying to have to do an out-of-source build because then your configuration files aren't where they normally are (at least on Win32 where there are no symlinks). |
|
|
(0013111)
|
Brad King
|
2008-08-20 09:36
|
|
Can't you just configure the location of the source tree into a header file and include it in the build? I've done this several times in the past. The application, if configured to run from the build tree, memorizes the build and source locations. |
|
|
(0013243)
|
Philip Lowman
|
2008-08-29 19:53
|
|
Sorry for the delay, I thought I responded to this already.
We've already considered the idea of configuring source tree locations into the source code during developer builds and rejected it.
There are other use cases though where an in-source build makes sense but they are more focused on "user choice" and not technical needs.
1. User doesn't like to constantly change directories or deal with having two windows/tabs open (source and build tree). (yes I've heard this complaint)
2. User only has one development platform and it supports multiple build solutions.
There is also the "pragmatic" reason to better support in-source builds (it's what most people are used to)...
Don't worry though, you can sleep easy. I probably won't have time to implement this feature. :) |
|
|
(0018834)
|
David Cole
|
2009-12-11 18:04
|
|
I don't think we should do this feature request either. Re-assigning to Bill - Bill, I think we should resolve this one as "Won't Fix"... |
|
|
(0018843)
|
Brad King
|
2009-12-14 08:54
|
|
As far as "make distclean" functionality, I think such a feature belongs in the hands of the version control tool. It knows exactly which files are source, which to ignore, and that all others can be removed safely. Modern version control tools have simple commands to clean out the entire source tree. If there is no version control tool, then it is a matter of removing the directory and re-extracting the tarball. |
|
|
(0041417)
|
Kitware Robot
|
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. |
|