(0010901)
Akos Maroy (reporter)
2008-03-25 02:47

yes, it would be very very handy & nice to have this feature..

(0013078)
Brad King (manager)
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 (developer)
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 (manager)
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 (developer)
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 (manager)
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 (manager)
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 (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
2008-03-24 23:02	Philip Lowman	New Issue
2008-03-25 02:47	Akos Maroy	Note Added: 0010901
2008-08-19 14:34	Bill Hoffman	Status	new => assigned
2008-08-19 14:34	Bill Hoffman	Assigned To	=> Bill Hoffman
2008-08-19 14:43	Brad King	Note Added: 0013073
2008-08-19 15:03	Brad King	Note Deleted: 0013073
2008-08-19 15:23	Brad King	Note Added: 0013078
2008-08-19 22:44	Philip Lowman	Note Added: 0013103
2008-08-20 09:36	Brad King	Note Added: 0013111
2008-08-29 19:53	Philip Lowman	Note Added: 0013243
2008-10-01 12:53	Bill Hoffman	Assigned To	Bill Hoffman => David Cole
2009-12-11 18:04	David Cole	Note Added: 0018834
2009-12-11 18:04	David Cole	Assigned To	David Cole => Bill Hoffman
2009-12-14 08:54	Brad King	Note Added: 0018843
2016-06-10 14:27	Kitware Robot	Note Added: 0041417
2016-06-10 14:27	Kitware Robot	Status	assigned => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:30	Kitware Robot	Status	resolved => closed

Notes
(0010901) Akos Maroy (reporter) 2008-03-25 02:47	yes, it would be very very handy & nice to have this feature..

(0013078) Brad King (manager) 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 (developer) 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 (manager) 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 (developer) 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 (manager) 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 (manager) 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 (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.

Relationships