Bug#27346: Perhaps a better way to handle Makefile.in/configure.in and Family on basic Console Apps

[W. Tasin]

Hi Van,


Van wrote:

> 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


ehhhm,
what do you mean? The presence of acinclude.m4.in?

I hope nothing from the GUI/KDE stuff will be tested by invoking 
./configure of a simple C application...


I guess you mean the following stuff inside configure.in:

-------
KDE_CHECK_LIBDL
:
dnl KDE_MISC_TESTS
:
AC_REQUIRE([KDE_CHECK_EXTRA_LIBS])
:
-------

right?

But these should be considered as macros from the KDE guys. Not 
necessarily checking KDE/GUI stuff.

KDE_CHECK_LIBDL is for checking "standard" shared-lib functions like 
dlopen()
KDE_MISC_TESTS (which is commented out) is for checking certain extra 
functions (crypt, socket, nsl....)
KDE_CHECK_EXTRA_LIBS is for giving ./configure the commandline options
--with-extra-includes= and --with-extra-libs=

That's all, no GUI or KDE checkings!!

I have to insert these for some reason concerning the shared-lib support 
and giving the user of your project the possibility to add special 
directories to configure (if he/she has maybe additional incs/libs 
inside another directory).

One solution:
If you really don't want to use these features (normally they shouldn't 
bother a normal c-application) you still have the possibility to copy 
configure.in.no_shlib to configure.in and you have the old situation w/o 
shared-lib support.

I'm using only a non-GUI-specific subset of the acinclude.m4.in inside 
configure.in.
The whole acinclude.m4.in is present in your project ... that's right, 
but the KDE-guys have more experience (and more man-power) to keep 
shared-lib support up-to-date (with all the existing platforms), so we 
are using this file. Of course we could write an own acinclude.m4.in, 
but why we should do so??

Another advantage would be the changement of a c-application to a
qt- or kde (mixed c/c++) project, but this is considered as a side-effect.



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


That's another point. Some older KDevelop 1.x primarily work with 
projectname/projectname directory structure.
So there were a difference between "Build" (invoking make inside 
directory "projectname/projectname") and "Build All" (invoking make 
inside directory "projectname").

In KDevelop 1.4.1 there is only a "Build All", so it is more directory 
structure independent.

All in all the project-management was and still is a subject of 
improvement.


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


As already told... there shouldn't be any GUI-include/define/libs 
checking inside...
if it would be, so tell me where you have found it by giving me your 
configure.in and your ./configure output.

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


Ciao

Walter

-- 
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>
<http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=0x7961A645&fingerprint=on>


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