Bug 287805 - EXECUTE_PROCESS() in a CMakeLists.txt command pollutes kdevelop's working directory
Summary: EXECUTE_PROCESS() in a CMakeLists.txt command pollutes kdevelop's working dir...
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Build tools: CMake (show other bugs)
Version: 4.2.3
Platform: Ubuntu Linux
: VHI major
Target Milestone: 4.2.3
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-29 05:51 UTC by Kishore
Modified: 2013-10-25 17:52 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Contains a CMakeLists.txt and kdevelop project file that help reproduce the problem (375 bytes, text/plain)
2011-11-29 05:51 UTC, Kishore
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kishore 2011-11-29 05:51:59 UTC
Created attachment 66171 [details]
Contains a CMakeLists.txt and kdevelop project file that help reproduce the problem

Version:           4.2.3 (using KDE 4.7.3) 
OS:                Linux

There is bad behavior in kdevelop with a CMakeList file that contains the EXECUTE_PROCESS() command like below.

EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -D<some special options> ${PROJECT_SOURCE_DIR}
    WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/build
)

Basically, i am building the same project again in a subdir with some other special flags. Soon as i open the project in kdevelop it seems to execute the same above command in the "~/Documents" folder (or kdevelop's current working directory) and I get all the "CMakeFiles" and other cmake generated files and directories.

Reproducible: Always

Steps to Reproduce:
1) Unzip the attachement. This should result in two files CMakeLists.txt and kdevtest.kdev. To start clean let there be only these two files in the directory.
2) launch kdevelop from that directory with the command "kdevelop -p kdevtest.kdev"

Actual Results:  
The directory gets polluted with the cmake build files resulting from the EXECUTE_PROCESS() command.

Expected Results:  
The directory should contain only the two files (apart from the hidden ".kdev4" directory) that were initially extracted.

Since this process could potentially overwrite preexisting files, it could even be considered severe in such cases.
Comment 1 Aleix Pol 2011-12-02 16:41:14 UTC
I'm sorry but I can't reproduce (in master). Can you try if it works there?

If it does, it's another reason to release a KDev 4.3 ASAP.
Comment 2 Kishore 2011-12-02 17:07:23 UTC
I don't have a kde dev env on this "netbook" which is the only machine i have access to. However, if it will try master on in some days.

However, apaku, in the mailing lists confirmed this behavior. See http://barney.cs.uni-potsdam.de/pipermail/kdevelop-devel/2011-November/041881.html
Comment 3 Aleix Pol 2011-12-02 17:22:20 UTC
Well if it doesn't work on master, please reopen.

I prefer to concentrate on making an awesome 4.3 release :).
Comment 4 Kishore 2013-07-08 08:14:32 UTC
On KDevelop 4.5.1 on KDE 4.10.90 from kubuntu's  PPA repositories. This problem still exists.
Comment 5 Kishore 2013-07-08 08:27:16 UTC
Also confirmed on KDevelop Version 4.4.1, using KDE Development Platform 4.10.2
Comment 6 Kishore 2013-07-08 08:36:36 UTC
Switching importance to "Major" since this bug resulted causing gdb to malfunction on my system. Explanation follows...

In previous releases of KDE on kubuntu, lauching kdevelop from kickoff or krunner would launch applicaiton with ~/Documents as the working directory. From recent times, the working directory is now ~/.

As part of my cmake process in my project i create a suitable .gdbint into the build folder to aid in debugging my embedded target. Previous to the above mentioned change, cmake build files include the .gdbinit were generated in the ~/Documents folder and I got used to ignoring that. With the recent release, .gdbinit file was created in my home folder and caused that configuration to apply gdb running on other projects as well. It took me a while to figure out why gdb was not working as it should.
Comment 7 Aleix Pol 2013-07-09 10:01:52 UTC
Git commit 0b7834c2671f98364323f9e1dbf9661a300545a0 by Aleix Pol.
Committed on 09/07/2013 at 09:58.
Pushed by apol into branch 'master'.

Don't run an execute process command if the working dir is unknown

M  +1    -1    projectmanagers/cmake/parser/cmakeprojectvisitor.cpp

http://commits.kde.org/kdevelop/0b7834c2671f98364323f9e1dbf9661a300545a0
Comment 8 Kishore 2013-10-25 17:52:17 UTC
I tried applying the patch referred to and a subsequent patch (569b55aa19) but it did not solve the problem. Is there any additional patch that needs to be applied on top of 4.5.1 to resolve this bug?