Bug 27346

Summary: Makefiles get compromised through the KDevelop Build | Autoconf and automake menu option
Product: [Applications] kdevelop Reporter: van
Component: kdevelop 2.x (obsolete)Assignee: KDevelop-Devel List <kdevelop-devel>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: 1.4.1   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description van 2001-06-17 07:16:13 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kdevelop
Version:           1.4.1 (using KDE 2.1.2 )
Severity:          normal
Installed from:    compiled sources
Compiler:          gcc version 2.95.3 20010315 (release)
OS:                Linux 2.4.3 i686
OS/Compiler notes: 

I've spent the past month working on a console application.

I have 3 .c files and 2.h files and the primary .c file is main.c  

I've created:  AUTHORS  COPYING  ChangeLog  INSTALL  NEWS  README  TODO

I develop my applications in /home/username/src/application-name/

I create the application-name/application-name.kdevprj file with the C wizard item and it gives me a default Hello World application as main.c.

I Add existing file(s) and replace main.c and add my other 2 .c files and their respective .h files and add the following to ~/src/application-name/Makefile.am and ~/src/application-name/application-name/Makefile.am:
INCLUDES= $(all_includes) -I/usr/local/include/mysql
LIBS = -L/usr/local/lib/mysql -lmysqlclient -lm # -lncurses -lsocket -lnsl

I do a Build | Autoconf and automake.
I do a Build | Configure.
I do a Build | Make and get:
sql_functions.c:28: mysql.h: No such file or directory
make[2]: *** [sql_functions.o] Error 1
make[2]: Leaving directory `/home/vanboers/src/btimeshell/btimeshell'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/vanboers/src/btimeshell'
make: Leaving directory `/home/vanboers/src/btimeshell'
make: *** [all-recursive-am] Error 2

I appreciate your efforts dudes but I'm heading back to vi and a directory that doesn't replace my directories using a very basic autoconf automake ./configure approach to finishing my application.

I have serius issues with KDevelop not giving me transparent ways to add include and lib paths to my makefiles and it can't be used for useful development if these types of process replace what I see in the IDE.

I just don't have the same level of confidence that when I change something in KDevelop it won't be changed by the slave process that I have when I'm using vi.

vi main.c -R always gets me back to where I need to go.

Back to the konsole I go.

Regards
Van

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 Van 2001-06-18 09:26:41 UTC
KDevelop is by far the best Linux/UNIX IDE I've tried but it would simplify
development/troubleshooting greatly if when you create a C application from the
wizard all the KDE/X stuff doesn't go into the macros for configure.in/am
Makefile.in/am.  They get huge and can take hours/days to troubleshoot when
they don't pertain to a simple console application 

Once done with the wizard I'd like to be able to delete main.c (hello world)
and create src and Documentation directories.  

I'd like to then add existing file thisfile.c thatfile.c thatfile.h into the src
directory and have the aclocal do it's magic along with
autoscan/autoheader/autoconf/automake and coordinate with the root .kdevprj file
without incorpating any GUI includes/defines/libs at all.  Quick development of
console esp. esecurity apps will promote the migration to the Linux Desktop
more quickly.

MicroSoft VisualC++ allows these types of processes but not nearly as
seemlessly as the basic C console application in KDevelop.  You guys really have
a huge opportunity here to convert those C developers and c development is far
from dead.

If security-minded types can use a strong OSS IDE like KDevelop to put those
applications together quickly KDE will have a much greater opportunity in the
Desktop Market.

My 2 cents but we're all on the same team I hope.

Pardon my rant but I've spent the weekend switching from emacs bloatware to
resolving to the tried-and-true vi since some things never change what you :w.

Best Regards
Van
-- 
=================================================================
Linux rocks!!!   http://www.dedserius.com/
=================================================================
Comment 2 John Firebaugh 2002-09-15 20:47:32 UTC
Should work much better with Gideon