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

[W. Tasin]

Markus Kuehni wrote:

> Walter wrote:
> 
> 
>>To finish my 2.000001 cents:
>>WANTED code which updates Makefile.ams, Makefile.(dist|cvs),
>>configure.in(.in) and admin-dir (and also considering the actual content
>>of the old files or using *.kdevprj).
>>
> 
> Hi
> 
> I'm pretty new to KDevelop and much of U*X, so please forgive me (and tell
> me) if the following is naive:
> 
> What always bugs me with these auto*-approaches is the ballast you have to
> carry with you. One of the biggest difficulties for a newbie is simply
> finding out which files are input and which are output in all that clutter
> (*.in.in.in).


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.

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.

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.

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)


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

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.


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


> 
> 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?
Don't forget ANSI c++ and ANSI c have no intention to support gui 
programming AFAIK.

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

> -- Mark
> 


Ciao

Walter


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