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

[Markus Kuehni]

> W. Tasin wrote:
>
> The central question is the implementation: how should it be and how
> much should it do.
...
> I see also the possibilty to handle as many cases as possible and step
> by step this will advance to a new project management.
> I think this should be done in gideon. In kdevelop it would break the
> "natural" concept of the old project management and it causes too much
> trouble in the next time .... take this as IMHHHHO.
>
...

Yeahh, I see.
It's always like that in computer science. First you think it's "just easy"
then point by point you uncover the exceptions, the exceptions to the
exceptions and so on...  ;-)

Basically, I think what you are telling me, is that far too many developers
really *need* to change the auto* stuff manually and the simplified "stream
line" mode I suggested would only help a small fraction.

> Now let's talk about the developer which doesn't change the
> configure.in.in or a Makefile.am and wouldn't insert his own m4-rules,
> so IMHO I don't need a changement in adding an additional  /mode/ or
> /option/ an update function does the same (it is possible to do it with
> the additional mode, but it isn't necessary - the bare bone tar could
> also contain the auto* stuff to have the same tarball for the user which
> install it by console and the one who use it with kdevelop and invokes
> the update function).
>
> The update is "simple":

Cough, cough...

> remove all "old" auto* stuff, untar the admin directory, untar the
> toplevel directory of the project template change the templates with the
> substitutions (version number, name, etc.), scan the subdirectories and
> recreate the Makefile.am completely new (with the help of *.kdevprj) and
> use the stuff additionally set in *.kdevprj, add the new admin directory
> to *.kdevprj.

Hmmm.. now, what I don't know is are you talking about a function that
exists already?
Or do you mean the user would have to do this step by step?

> That's it and you would need the same function in your
> concept.

Yes, and if this function already does exist (and I can invoke it through
the GUI) then there is nothing else on my wishlist ;-)

> You will loose the manually added flags in Makefile.am and all manual
> changements of configure.in.in (CXXFLAGS, *_LIBADD, AM_*FLAGS, etc.),
> but the developer who knows about the stuff could replace it manually,
> right?

Exactly right.
The question is "how many developers are auto* hackers, how many are not"?

> I don't like it much, but I would live with this situation, if I knew
> that this won't be the final situation.
>
> This is quite the same as you have with the "generic mode" (apart from
> the tarball size), isn't it?

Yes, exactly.

> I guess already 80% of these informations are inside *.kdevprj.
>
> But if we are talking about a concept changement please have a look at
> the features I mentioned above.

No, no real concept change.
I agree that KDevelop will probably never be able to replace/abandon the
auto* capabilities. They're simply much too powerful (although they are a
mess IMHO).

> If you are interested I will give you a small c++ project of mine, where
> I added some simple m4 rules inside configure.in to check for sendmail
> and a custom Makefile.am. All written with kdevelop, only to show how
> fast configure.in can (and maybe should) change.

One question here: could this be done in an "additive" way?

I mean instead of tweaking one global file (and afterwards not being able to
distinguish user code from kdev-generated code) one could introduce a new
file extension (say .konf). The filename could contain a number (e.g.
sendmail.2.konf) to indicate ordering (similar to the init rc stuff).

Each time KDevelop detects a change in .konf files, it

1. generates a pristine configure.in according to the project template and
does the magic on it (as it does when you create a new project)

2. scans for .konf files (in the project registry) and copies their contents
to certain parts of configure.in according to the number in the name

This way auto* hackers could still write their own stuff and better yet
could distribute their work to others. If I needed to check for sendmail one
day I could probably get your sendmail.2.konf and just copy/register it to
my project ;-)

The same could be done for .am fragments in their respective directories.
The following is not to be take serious: We could name these .kake as in
"Kdevelop automake konstruction entry" or "piece of [the] cake" ;-)

Often-used and well tested fragments could then be distributed with KDevelop
and even given a checkbox in the project settings GUI.

Ciao.

-- Mark


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