The Autotools issues

Roland Krause rokrau at yahoo.com
Thu Sep 4 17:17:45 BST 2003


First of all, 
all KDE packages on Redhat are broken to a certain extent from version
RH-8 on. Fortunately you can get good packages from the KDE for Redhat
project. http://kde-redhat.sf.net/

Second, RH-9 comes with three different versions of automake installed,
1.4, 1.5, 1.6 and they also install autoconf in at least two different
versions because some projects didnt make the change. 
Get rid of these extra ones!
Here is what I have: 

rpm -qa | grep auto
automake-1.6.3-5.fdr.3.rh90
autoconf-2.57-3.fdr.4.rh90

This should look similar for you. 

Third, when using older KDevelop-2.x projects with newer automake, you
need to once edit your configure.in or configure.in.in files because
the syntax for AC_CONFIG_FILES and AC_OUTPUT command has changed.
Create a new project, check out how it's done there and apply the
changes to your old project. 

Yes, automake and autoconf are broken by design. 

Finally, all is better in gideon, unfortunately feature freeze is far
away for the beast and it crashes frequently. 

Roland

--- Dorin Lazar <lazar at deuromedia.ro> wrote:
>    Hello,
>    I write you as a programmer that has had the sad experience of
> moving some 
> project from a version of kdevelop to a newer version. (that was with
> 2.x). 
> More, I moved from RedHat 7.3 to RedHat 9 (where somehow the kdevelop
> is 
> totally broken - unable to create a simple project). And I think that
> RedHat 
> 9 shows the same problems as those I had - when the kdevelop expects 
> different autotools series. The configure creation fails, and using
> an old 
> configure is not an option - because you might want to change
> something in 
> the project.
>   Also, there are some problems when simple changes in the project
> file (like 
> the name of the author) will rebuild the configure script - creating
> an 
> unusable version - the solution being to update the Makefile.am
> manually. But 
> this behaviour occured on an already desynced system (with autotools
> changed 
> to the versions from another system, and stuff like that).
>    A more detailed description of the issues I can't make - it was
> truly 
> upsetting the effort needed to move to a different version, so I
> haven't 
> recorded all the problems - but I think that you are familiar with
> this. Is 
> there any way to solve this problem? or are the autotools so broken
> that a 
> simple change of version upsets the project?
>    The reason I write you is to ask if the new gideon will be more
> robust 
> regarding this issue? Or perhaps a better system should be thought?
> How could 
> the build system be changed/or the configure generation model (if
> needed)?
>    Dorin
> 
> 
> -
> to unsubscribe from this list send an email to
> kdevelop-request at kdevelop.org with the following body:
> unsubscribe your-email-address

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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



More information about the KDevelop mailing list