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

[W. Tasin]

ian reinhart geiser wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Monday 05 November 2001 09:51 am, you wrote:
>
>>Ouch!
>>
>>So, is it correct to say all the projects created with kdevelop (some
>>versions at least) will cease to work on newer systems?
>>
Hmmm...
with kdevelop?
I think many projects (even outside from kdevelop) which use 
automake/autoconf will now have problems with the new versions of 
autoconf and automake, because the checking of Makefile.am, m4-macros 
and configure.in(.in) is stricter now.

>>
>>
>>Because sooner or later all distributions/U*Ces will upgrade to the newer
>>autotools, won't they?
>>
>
>Hmmm, this is not a good thing.
>I wonder if it would not be pudent to regenerate the admin directory on 
>startup of kdevelop?  
>
In the actual situation it needs always root rights or every user has 
its own admin.tar.gz?

>This directory should not change at all, and i think 
>this is all we need to change for it to work?
>
>Thoughts?
>- -ian reinhart geiser
>
Sorry, Ian but I think updating only the admin.tar.gz isn't the solution.

The best way IMHO is to update manually, I know a hard way but the most 
secure.

In the older automake/autoconf systematic there was nearly no way to 
automate an update, because you would need a parser for configure.in.

Now with the introduction of the admin/ dir and some new Makefile rules 
the project independent parts are moved to this directory.

So the problem has been reduced to the configure.in.in, but even this 
can still be a problem. I think for kde project types we all (thanks to 
Coolo, David and Co.) are on a good way to update only the admin 
directory and increases the possibility to automate the update process 
of configure.in.in.
Other project types (especially the terminal project types) cause more 
trouble, even if the kdevelop user does more than the standard checkings 
inside configure.in.in or writing own .m4 rules --> minimalistic parser 
for configure.in(.in) ?!

Maybe an external script to update an existent project could handle 85% 
of these cases. But this is IMHO almost an own project or at least a 
part of the new project management. 

All this was only considering corrections caused due to the newer 
autoconf and/or updating to the improvements of kde's m4-macros (namely 
in acinclude.m4.in) and libtool-m4-macros/scripts

In this special case we also have to consider the updates (better 
"corrections") for automake 1.5, so we also have to look at all 
Makefile.ams, because there are some duplicated entries, which were no 
problem for the older automake versions, but now they must be deleted. 
Fortunately this happens not too often.


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


Ciao

Walter


-- 
The KDevelop project: tasin at kdevelop.de [www.kdevelop.org]
--
oohhh sveglia.... il mondo e' ammalato, ma x colpa di chi.........
(Zucchero)
:-------W. Tasin, FB 04,FHM-------------------PGP-KeyID:0x7961A645----------:
<Key-Fingerprint: 1610 835F 0080 32F4 6140  6CF7 A7D0 44CD 7961A645>





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