[Qt-creator] Remote Linux plugin and CMake

[André Pönitz]

On Mon, Sep 09, 2013 at 09:27:11PM +0200, Stephen Kelly wrote:
> André Pönitz wrote:
> 
> > On Mon, Sep 09, 2013 at 08:09:23PM +0200, Stephen Kelly wrote:
> >> André Pönitz wrote:
> >> 
> >> >> This is needlessly and deliberately crippling the user experience with
> >> >> CMake.
> >> >>
> >> >> You should reconsider.
> >> > 
> >> > Where is the patch from the CMake community?
> >> 
> >> This is a poor deflection of an excuse for doing the wrong thing.
> > 
> > Not really. "A bird in the hand is worth two in the bush."
> 
> Again, just deflecting attention away from doing the wrong thing.
> 
> > I have the choice between supporting an existing patch that comes from a
> > CMake user which is declared by him as "serving the purpose" and
> > supporting an approach that does not have a patch
> 
> A superior approach which will serve more than one user. It will instead 
> serve all CMake users.
> 
> > , and for which I rate the chance of showing up at all at about zero.
> 
> Why is your expectation so low?

Extrapolation from the past.

A look on the cmake plugin gives 41 "external" patches (out of 728) spread
over almost five years.

This makes roughly one in six weeks, and includes global refactorings that
"accidentally" also touch the cmakeprojectmanager.

That's _quite_ a bit below the average and I see no reason to believe that
the half of "randomly appearing cmake patch" that would be the "expected
average" for the remaining three weeks until 3.0 feature freeze will
address the cmake deployment problem.

In fact, I am grateful to Oleksii to provide a way to get _any_ kind
of remote deployment of CMake based projects, something that have been
sorely missing for years, and something that has _not_ been addressed
by the "official" CMake community.

> Why do you think I'm on this mailing list and this thread.

I'll send my best guess in private mail.

> Why do you think I keep asking Tobias Hunger about his build configuration 
> patches? He recommended a few weeks ago that I wait for them before diving 
> into the CMake related code in creator.
>  
> > It has been pointed out that both approaches can be implemented, and
> > can co-exist.
> 
> That is not correct. They can not co-exist. What is installed by running 
> make install may not be the same as what is in the deployment file. You 
> would have to have UI to allow the user to configure which one is 
> authoritive.

Neither a checkbox in a "fat" deploy step nor giving a choice between two
different deploy steps is rocket science. The default could be the
"official" "CMake community blessed" solution _once it exists_, and there's
always the option to make that the only choice when it's established that
it is uniformly better.

> That's just more bad user experience.

_Bad user experience_ is having none of the rather extensive "remote"
facilities of Creator available in QMake based projects only. That's a
needless restriction and Oleksii lifts that restriction for quite
a few cases. That's _good_ in my book.

> > So if the "official" CMake community wants their opinions
> > reflected in the code they are heartily invited, at any time.
> 
> Twice previously I pointed out the problem that installing is the only way 
> to get the correct answer, and I pointed out why:
> 
>  http://thread.gmane.org/gmane.comp.lib.qt.creator/8995/focus=9008
>  http://thread.gmane.org/gmane.comp.lib.qt.creator/8995/focus=8997
> 
> There was no acceptance of the problem statement I presented and no 
> acceptance that it's the only workable solution.
> 
> Yes, I can implement it. I thought my recommended approach was already 
> rejected. Please be more clear about that. Or maybe I need to wait for 
> Daniels decision?

Daniel said

  "I don't want to maintain multiple ways. That's beyond what I consider 
  reasonable effort for the benefit. (Others can disagree and volunteer.)
  I want one solution."

Let me put emphasis on the part in parantheses. There are limited
resources, "CMake support" ranks generally as "Nice to have", offering help
to get in and maintain _one_ approach is very reasonable.  This is not a
rejection of your approach, in fact it explicitly opens the door for
_any_ alternative approach ("disagree and volunteer")

The two "negative" responses towards your approach were related to (a) the
fear of performance issues related to the 'make install' step and (b) the
fear that nobody will implement it. (a) can be disposed of by showing that
it is not a problem _in action_, which might be easy when (b) is dispelled.
(b) can be dispelled by providing an implementation, i.e. answering the
question "Where is the patch?"

Andre'