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

[W. Tasin]

The central question is the implementation: how should it be and how 
much should it do.


Markus Kuehni wrote:

>>...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?
>
at the project bootstrap time yes... apart from this, more stuff 
*should* change inside configure.in(.in) and Makefile.am, for a nearly 
perfect project, which catches some tests already in configure (do I 
have the libraries, inclusion of certain flags, CXXFLAGS, etc.).
I know many users are happy with the "state-of-the-art", but if the 
abstraction layer was good enough IMHO kdevelop should handle these 
cases, too.
 

>
>How many users do actually add new m4 macros?
>
In the kdeveloper-developers team I know Bernd and me ... hmmm... for 
all the others we would need a poll ;-)

>
>
>How many do add new AC_-tests?
>
Generally I hope nobody except libtool and acinclude.m4 developers ;-) 
... the others should add an own .m4-file (added by Makefile.am or maybe 
in configure.in.mid or configure.in.bot) and use another prefix like 
KDEV_ AFAIK (correct me if I'm wrong).

>
>
>And for those requirements remaining, isn't there a simple way to add 90% of
>these through KDevelop dialogs?
>
with the KDevelop dialogs we are at the beginning (and unfortunately 
since long time still at the beginning). Maybe additional effort should 
be done in gideon?

There are *some* examples, which should be automated, like:
- updating the version number of the project,
- updating the version number of shared libs (like described inside the 
libtool manual),
- adding CPPFLAGS, compiler switches, LDFLAGS and LIBADD for only 
Makefile.ams of a sub project and for the whole project inside 
configure.in (depending whether they are project depending or only 
session depending), e.g. asked in thread 
http://lists.kde.org/?l=kdevelop&m=98418127928001&w=2 and some others.
- ...

an almost perfect situation would be, if
- macro functions of acinclude.m4.in could be selected by the user and 
are registered inside *.kdevprj so your aim can be claimed without any 
lacking situation.
- Makefile.ams were parsed, so the complete file would be encapsulated 
inside #### kdevelop (begin/end) ##### and all possible flags could be 
inserted by KDevelop dialogs.
- configure.in.in should be also created automatically (especially for 
project types other than kde projects)
- and updating system which knows what flags are already inserted by 
invoking a new acinclude.m4 call, e.g. AM_PROG_LEX() and where to put 
the manual added flags inside configure.in(.in)
- going a little bit away from the hardcoded creation of Makefile.am, so 
rules like
install-data:  ......
uninstall-data: .....
can be easily replaced by a new method:
app1dir =  ....
app1_DATA= ......
bin_PROGRAMS = test1 test2
test1_SOURCES = ...

>>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.
>

The only difference I see now is another way to make a kdevelop 
distribution, with all the directory structure but without any 
Makefile.am and configure.in.in and auto* stuff (no difference IMHO if 
you implement the simplest autoframe update function - as I will 
describe later).

>
>
>- 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!!!)
>
Yepp I can remember... long time ago... :-)
and that's what I meant it isn't that easy to change it (if you want to 
handle more situations than the "default" case).

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.

>
>
>- 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.
>.....
>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.
>

Sounds great [I don't know how far this (precompiled headers/function 
level linking etc.) can be implemented with the gnu compiler and 
framework, but this is another topic]. One thing I still haven't understood:
To compile in the "generic mode" on another machine with another 
framework can cause IMHO problems with the newer/older configure.in.in. 
So this one should also be created by kdevelop... so here we go again, 
kdevelop has to know how to create an own configure.in.in (and maybe 
some changements in the toplevel Makefile.am) and that is the problem I 
see. Try only to compare the configure.in of C/QT template of the old 
kdevelop 1.4 with the one of the actual CVS kdevelop 2.0.1, even if 
somebody has only added CXXFLAGS somewhere in configure.in.

This doesn't mean that it isn't impossible. It is only difficult....


I think one thing is clear:
The project management lacks.

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":
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. That's it and you would need the same function in your 
concept.
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?
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?
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.

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.

>
>>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.
>>
>>.....
>>
>>>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?
>
as described above...

Ciao

Walter
PS: I think my english is fuzzier :-)



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