Kdevelop modifies files - even excluded files!

[Erik Rull]

Hi Milan,

thanks. This explains a lot to me. It seems to be clear now where the issue
comes from.

A straight forward fix seems actually not to be possible.

What about "make -p"?
This should print the whole make database - of course a lot of stuff around
but filtering out all targets should help and provide similar information
as the make -n...

If you take the -W argument the file is treated as completely new and it
might be possible that some make rules are not only printed but actually
get executed - maybe due to other reasons within make - and this causes
finally to corrupt the .d files - the "why" is not yet clear for me.
But on the other side this is the one and only solution to get the printout
of the rule via -n because uncalled rules are not printed.

Think about a make -n -p approach...

Best regards,

Erik


Milian Wolff wrote:
> On Dienstag, 1. März 2016 21:46:37 CET Erik Rull wrote:
>> Hi all,
>>
>> strace tells me the culprit - it seems to be my own Makefile!!
> 
> OK, this verifies then that it's our make file resolver.
>  
>> But - it's called and causes a forced execution of parts of my Makefiles.
>> And this then seems to force update of some files - even if nothing has
>> changed.
>>
>> Why is make executed at kdevelop startup?
>> Any why is the behavior different compared to calling it from the
>> commandline?
>>
>> My makefile is -jN safe - so even background execution in parallel should
>> not cause such a behavior.
>>
>> So I would carefully assume that newer kdevelop versions may show this
>> behavior, too.
>>
>> I would like to run make only from the commandline - not within kdevelop.
>> Is it possible to customize the project in a way so that this the makefile
>> is only parsed and not executed?
> 
> You are not to blame. The issue is the above and before mentioned 
> MakeFileResolver in KDevelop, which tries to run
> 
> make -k --no-print-directory -W $abspath -W $relpath -n ...
> 
> strace / ps -aux should show the full invocation. The output of that command 
> is then parsed to find calls to the compiler which then gets parsed in order 
> to find include paths and defines for our semantic code analysis in KDevelop.
> 
> Note the "-n" parameter, which should trigger a dry-run mode of make. 
> Apparently, that is mode is not free of observable side-effects...
> 
> Suggestions as to how to fix this are welcome! An obvious candidate for a 
> patch would be to just disable this code (optionally) and rely on the user to 
> supply all defines and include paths.
> 
> If you are stuck with KDevelop 4.6, then I don't think there's an easy way to 
> workaround this issue.
> 
> Cheers
> 
>> Milian Wolff wrote:
>>> On Tuesday, March 1, 2016 3:33:15 PM CET Michael Goltsman wrote:
>>>>  On Tuesday, March 1, 2016 5:24 PM, Milian Wolff  wrote:
>>>>>> Kdevelop 4.6.0 on KDE 4.13.3 (available via Kubuntu 14.04)
>>>>>
>>>>> This is extremely old. I urge you to update to the latest KDevelop 4.7.x
>>>>>
>>>>> before doing anything else. Potentially this issue is resolved there
>>>>> already.
>>>>
>>>> The upgrade is extremely hard if you do not want to upgrade the entire
>>>> system.I've spend several days trying to compile KDevelop from sources on
>>>> RH 7 and failed at the end. I just could not spend more time on taking
>>>> and
>>>> building new packages. KDE requires so many latest tools and applications
>>>> that it is almost impossible to build it for someone who is not
>>>> accustomed
>>>> to it.
>>>
>>> Yes, I realize that this is an issue for some people. But I also want you
>>> to understand that we do not have the manpower, or interest, in
>>> supporting outdated versions of KDevelop. Version 4.6.0 is 2.5y old - not
>>> old by corporate standards, but old enough in FOSS standards.
>>>
>>> In general, as a developer, I can only recommend you to use the latest
>>> tools available to you to increase your productivity. If that means
>>> installing a VM with a more modern distro, then it may be worth it. If
>>> neither is allowed by your employer, you'll either have to live with the
>>> brokenness, or seek a new job ;-)
>>>
>>> Cheers
> 
>