Building a library and executable with 300 C++ files.

Aleix Pol aleixpol at
Tue Nov 30 00:12:43 UTC 2010

On Tue, Nov 30, 2010 at 12:48 AM, Michael George Hart < at> wrote:

> Hmm...... did I say all the files were in one directory or did I say I have
> 300 plus files used to build executables and libraries? Hmmmm..
> We'll that was not the point of bringing any this to your attention. What I
> am trying to bring to your attention is there are a class of softer
> developers who do not care about knowing extraneous stuff like build
> systems. What they care about is writing and testing their software models
> without distractions such as a build system. The prior kdevelop3, vs,
> eclipse, java bean etc don't seem to have the kdevelop4 build system
> distractions; you simply add files build, run, debug and install
> The problem is that most of you guys out know each other and probably all
> talk on the same forums so when you talk to each other it's like bouncing
> ideas off yourselves. So when an outsider comes and tells you have created
> something technically superior but on a whole useless to the average
> developers who simply wants to build a software model and install it into
> some default location it would be a good idea to take notes
> Sent from my iPad
> On Nov 29, 2010, at 1:00 PM, Syron <mr.syron at> wrote:
> > 2010/11/29 Michael Hart < at>:
> >> Being a very senior and experienced C++ developer for the most part all
> I
> >> ever cared about was the C++ language and the various APIs I used in
> getting
> >> an application to market. So what may seem appalling to you, I can only
> make
> >> the assumption I was using automake as my build tool.
> >
> > I think it's strange that you're a senior developer and have never
> > dealt with any build system - understanding how build systems work is
> > an important thing, that's what I learned as soon as I wrote my first
> > project with more than one file. And I am also worried about the fact
> > that you have 300 C++ files in _one_ directory, that seems like a big
> > mess.
> > If you spend some time learning a build system (qMake, CMake,
> > whatever), you will soon learn how powerful they are.
> >
> > Kind regards,
> > -- Syron
> >
> > --
> > KDevelop-devel mailing list
> > KDevelop-devel at
> >
> --
> KDevelop-devel mailing list
> KDevelop-devel at

Don't get us wrong, we take notes. We try to make our best also. For what
it's worth, KDevelop4 is the best IDE when it comes to assisting the user to
get his CMake work done and the only one that can hint the user on what he's
doing (at least, as far as I know).

We are aware that there are different solutions that other developers prefer
and we are also targeting that use case, but always from a point of view
that doesn't jail the developer into our IDE. I have never liked that
developers have to work the IDE the way it's expected to be used, we have
tried the best solution we have been able to in the most general use case
we've seen. The choice of having CMake as the first and most important build
system (the only with project editing so far, which is not trivial) is that
we are mainly targeting KDE and CMake is the way to go there, that doesn't
mean it's not going to change in the future. We have Makefile support
working, which is also very important in the free software community and we
have upcoming QMake support which is going to solve some of your problems

Said that, you can either join and help us or just expect that your critique
is not understood by us as simple trolling so that we make KDevelop the tool
you want it to be.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the KDevelop-devel mailing list