AW: AW: AW: C/C++ projects don't work for suse 7.2, suse7.3 and upcoming kdevelop 2.0.2

[Markus Kuehni]

> W. Tasin

> Markus Kuehni wrote:
>
> > Walter wrote:
> >
...
> It also bugs me, but we have to see the history and the advantages you
> get from it.
>
> kdevelop was first only used for the KDE/QT projects and like gnome
> (with autogen.sh/autoconf/automake) they are using a certain system
> (developing environment) to get a kind of the platform independance for
> different compilers, frameworks (Solaris, BSD, gccfront, egcs etc.).
> Here you had and you still have more than the intel-platform like MS
> Wi**d*s HAD once ago.

I totally agree with you and I think I did not make myself clear enough:

We should distinguish between the core KDevelop project and the "product
thereof" that is a full fledged auto*-tools compliant and tar-ball ready
build and package environment.

IMO Kdevelop already has the capabilities to add a completely new layer of
abstraction and code generation. I can bootstrap and extend a project using
KDevelop only (I tried). All the other stuff is actually generated isn't it?

How many users do actually add new m4 macros?

How many do add new AC_-tests?

And for those requirements remaining, isn't there a simple way to add 90% of
these through KDevelop dialogs?

> Even creating an own compiler, debugger and IDE would break the goal of
> kdevelop IMHO and why we should do so, we would have to invent the wheel
> again....
> So using the compilers from the UN*CES is still what we should do, but
> this means to have an developing environment which will be always
> up-to-date and due to lack of manpower we have not the possibility to
> maintain this.

No, no. I was obviously very unclear in my post.

NOTHING should change in the way KDevelop /works/ to configure, make,
compile, debugs, package, etc.

One should simply be able to separate all the /added/ /means/ to achieve the
above from the /core/ /project/ .

> Another point: Don't forget first at all kdevelop was used to develop
> kde applications and kde uses the automake/autoconf stuff.
>
> That was the historical reason, now the advantage from my point of view:
>
> If everything of the automake/autoconf stuff inside your project is ok,
> you will have the possibility to give the tarball of your project to
> one, who wants to compile it under FreeBSD or Solaris etc. and it SHOULD
> work.
> If a new kind of linux distribution or a new kind un*x comes up the gnu
> software foundation tries to adapt this for the new stuff and step by
> step the parts (autoconf, automake, libtool, etc.) will be updated.

Yes, of course. Again the auto* stuff and all the other means should remain
the same as now.
The difference would simply be this:

- if the receiver of my package has KDevelop (or is willing to install it)
he/she could get the "bare bones" project only and let KDevelop generate the
rest.

- if the rules and templates of the environment (auto*-stuff etc.) change, I
can let a newer version of KDevelop regenerate all that to reflect the state
of the art .

(this thread was actually started by the fact that a newer version of the
auto* tools breaks many of the /existing/ projects generated with
KDevelop!!!)

- this new abstraction would introduce a new level of flexibility to
change/optimize how things are done in a project

Add precompiled headers?
Add function level linking?
Add multiple configurations per project (as in Visual Studio)?
etc.

These things are only easily possible if one switches from the auto*
approach of "copy semantics" to "reference semantic" (or let's say "generic
semantics").

As "copy semantics vs. reference semantic" implies, the object referred to
is still there meaning the whole auto* suite is still being used! It's how
you handle it and the consequences thereof that are different.

The auto* &Co. scripts to do the job are simply generated instead of being
edited by hand.

KDevelop already does this if you only use the GUI, doesn't it? The only
thing "I want" is a /mode/ where you can tell KDevelop to remember all chang
es you made through the GUI and be able to "replay" that.

Instead of using (by their very nature) imperfect tools (such as libtoolize)
to "upgrade" existing project scripts each time a new aspectual feature is
introduced, one could simply regenerate the whole lot from the basic
"skelleton" knowledge maintained in the KDevelop project.

> Remember first we had only make and several Makefiles for every special
> machine (or environment variables which had to be patched by the
> end-user of your product); then there was imake (which creates first
> Makefiles from Imakefile) now as another step of the evolution we have
> automake/autoconf which creates Makefile.in from Makefile.am and then by
> invoking "configure" converting Makefile.in to Makefile.
>
> The more abstract it's getting the more complicated it becomes for the
> developing user (in this case the kdevelop-user). (NB: I personally
> think with Makefile.am and configure.in, it's less complicated then
> Imakefile, but I was also scared the first time I've seen it and that
> what I miss is a kind of tutorial of auto*-stuff - that's the greatest
> problem at all IMHO)

The problem with the auto* tools is that when adding a layer of abstraction
they don't hide the underlaying layer but merely add to it.

And this is still being done long after the initial "hen and egg" problem of
distribution is solved.

Each book and tutorial I've seen so far continues to elaborate on the basics
instead of just presenting the newest/highest-level API. This is very
confusing and violates the basic principles of encapsulation and
abstraction. It's as if somebody forced you to master semiconductor physics
and machine language before you're allowed to write C or C++.

> > In most cases of KDevelop-ed projects (from scratch) all you'd
> need to save
> > is
> >
> > 1. the wizard template type used to boot-strap the project
> > 2. a list of the file added afterwards
> > 3. the settings set through one of KDevelops dialogs
> >
> > Of course I know you can directly go to the auto*-files and
> change things,
> > but if I *don't* *want* *to* , I should be able to let KDevelop know.
>
>
> Yes, until a certain point you are right; but this is the task of a new
> project management and as already described in the last mail it isn't
> that easy.

Hmmm... why?

> One advantage you would give up with this method is to distribute a
> package as tarball, because everyone who wants to use your "product"
> must have kdevelop and KDE to compile it, there isn't ONE EXE file, the
> binary differs from system to system and from distribution to
> distribution (e.g. look at the different linux-file system specs
> /usr/lib/qt, /opt/kde2, /opt/kde/share/doc... only a little example).
> With the actual method you can untar it and build and install it from
> the console.

I think it's now clear that I don't want to change the way configure and the
auto* tools work but how you get there.

> > There should be a global option called "let KDevelop manage my project"
> > which operates only on the above input and if necessary (when tools and
> > templates change) re-generates/overwrites all auto*-files.
>
> We are still in the same position as described above. KDevelop hasn't a
> project management, which allows to do so. You would have been
> up-to-date with all project-types (especially with the GUI one's) and an
> update system, which allows also to interpret new stuff and insert it at
> the right place of the right file, without corrupting an user changement.
>
> Think about how often the macros of acinclude.m4.in or gnome.m4 have
> changed and are getting new features/improvements (python support, java
> support, etc.). If KDevelop wouldn't use these stuff it had to invent
> something similar, which had to be equivalent in every version and
> development stage of the GUI/compilers/frameworks (and the IDE).

The approach I suggested would not at all change that. On the contrary. It
would even support more drastic changes in the way certain project types are
handled!

Of course allthis is only possible if the user does not manually alter the
auto* files. So this new /mode/ should and can only be an /option/ (as I
said before).

> > This way a "pure" KDevelop project (within the concept of one
> of the wizard
> > templates) could be distributed in a very compact and abstract
> form that is
> > capable to evolve and adapt to different platforms (Windows, one day?).
> >
>  > There would just be the .kdevprj file (minus the auto*-files content),
>  > ChangeLog & Co. and the real source files.
>
> Sounds like own compilerS, debuggerS in one ide. IMHO thats more the
> intention of some java ides (JBuilder, Forte, etc.), but for c- or c++
> language usage?

No, not at all. See above.

> Don't forget ANSI c++ and ANSI c have no intention to support gui
> programming AFAIK.

Dito.

> > Please don't misunderstand me: I know auto*-tools are very powerful and
> > valuable for distribution and configuration and they should
> still be used in
> > the background (on U*X).
> >
>
> No, I don't misunderstand you...

Well, yes I think you did. That's most probably due to my "fuzzy" english...
;-)

> I already searched for another method
> (and e.g. other make systems where also discussed here), but it is
> really hard to find an effective and realistic compromise...

Hmmm... I'm still pretty much convinced KDevelop already has all the
necessary building blocks. At least for a majority of "plain-vanilla"
projects.

One would have to "record" the project relevant actions as you go along
using the GUI and to be able to "replay" these...

Maybe some additional GUIs for the most common auto* macros, like checking
for and configuring libraries and headers, need to be added.

-- Mark


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«