https://bugs.kde.org/show_bug.cgi?id=369227
Bug ID: 369227
Summary: relative build directories
Product: kdevelop
Version: unspecified
Platform: Other
OS: All
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: all build tools
Assignee: kdevelop-bugs-n...@kde.org
Reporter: rjvber...@gmail.com
Working on a few projects on different hosts I realised I'm missing a feature
from Xcode I never gave much thought too. Come to think of it, I think MSVC has
this feature too:
You can take a source tree containing an Xcode project anywhere (via git
checkout, or say on an external disk), open the project in the IDE on no matter
what host with a compatible Xcode version, and it will build without having to
redefine the build location.
This is (presumably) because they store the build directory as a path that's
relative to the project file.
I realise that CMake and possibly QMake too store full paths in the Makefiles
they generate, but even with that limitation it is still useful to have support
for relative build directories for projects shared via VCS.
Reproducible: Always
Steps to Reproduce:
1. Set up a project and export it to a VCS like git, including the .kdev4
project file and directory.
2. Check out the project on a host with a different filesystem layout, in a
different location on the same host or as another user.
3. Open the cloned project.
Actual Results:
The build directory will not be found and will be expected in an inappropriate
location. Or possibly the original build directory will be used (when the a
working copy was made in a different location on the same host).
Expected Results:
The build directory might not exist in the initial working copy but it should
still be expected at the same location relative to the project file. With
KDevelop that could be the CMake/QMake/whatever file that contains the actual
project description, or the foo.kdev4 file.
Xcode also makes collaboration easier by storing certain project settings in
user-specific files which would typically not be under version control.
KDevelop could do the same in the .kdev4 directory:
foo/.kdev4/foo.kdev4 : shared settings
foo/.kdev4/${LOGNAME}.kdev4 : user-specific settings
Prime candidates for such user-specific settings would be the selected build
directory but also absolute build directories (esp. if they're under the user's
$HOME) or simply build directories that were marked private during their
declaration, because any of their settings contain something user or
host-specific.
--
You are receiving this mail because:
You are watching all bug changes.
