Build system (was Re: Future of KDE Development)
Alexander Dymo
adymo at mksat.net
Tue Feb 15 21:42:24 GMT 2005
On Tuesday 15 February 2005 21:55, Guillaume Laurent wrote:
> Well, I still fail to understand why on earth would they do that, except
> for initial project import. Once this is done, the IDE has its own build
> system (MSVC, Eclipse or Idea have that), and may possibly export the
> project to whatever build system it knows. But using makefiles to store
> current project data is insane.
You mix project data (project settings, vcs settings, etc.) with rules
to build the project.
Java IDE's don't need much rules to build the project. It's pretty
straitforward.
KDE/C++ IDE need to know about build rules. And those build rules
are stored now in Makefile.am's and probably they will be stored in
SConscript's. As a simple example, consider what should an IDE do
if you add a .cpp file into your project? Obviously, it need to modify
Makefile.am or SConscript.
I'm not talking here about storing project data which is currently done
in nice projectname.kdevelop files (xml). I'm talking about build rules
and how easy the IDE can recognize them.
> > That doesn't solve the problem of writing changes back to the project
> > file. If you changed a list of files in a target withing the IDE, you
> > should write it back. Here the troubles with build file syntax, user
> > formatting, etc. arise.
> So you just recreate the whole thing and move the old files to
> Makefile.am.bk or something.
Heh, who would use such an IDE? I wouldn't.
> > autotools approach. But that doesn't solve the problem with IDE
> > which won't know about your extensions.
>
> So ? The IDE has to be able to perform the same tasks as your extensions
> anyway, so it can export back something close enough. Although what is
> often possible is to specify some pre/post build tasks which are targets of
> the old build file, but then it's relatively easy enough to move these to a
> separate file or to isolate them somehow.
At this moment, KDevelop relies on manually written .m4, configure.in(.in)
and files in admin/ directory. This will not change in the future. IDE will
not stop you from using additional tools to extend the build system.
I'm just dreaming about the build system that could tell an IDE what
extensions are present. And.... I _do_ know I'm dreaming ;)
--
Alexander Dymo
ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine
More information about the kde-core-devel
mailing list