[gentoo-user] [OT] AUTOTOOLS

[gentoo-user] [OT] AUTOTOOLS

[Rafael Fernández López]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

Hi,

	I'm downloading some KDE apps source code to know how Makefiles.am are 
pointed. I've become surprised because I've seen that for example, amaroK has 
been developed under KDevelop.

	I have been searching a bit and I can't find any QT app that use METASOURCES 
= AUTO, and with its Makefile hand-written (no IDE). I'd like to know if 
there is a way for creating 'acinclude.m4' and Makefile.am automatically by 
console (no KDevelop) if we know that that app will use QT (or KDE libs).

	I have seen that all KDE apps include acinclude.m4 that starts with something 
like "This file is part of the KDE libraries/packages"... But what I could 
see too is that if we create a simple KDE project under KDevelop, my 
configure.in will be VERY SIMILAR to amaroK's configure.in, so I'd like to 
know what console command does KDevelop run to generate it (because I tried 
to search it for, but no results).

	It was strange for me to read this:

	# Original Author was Kalle@kde.org
	# I lifted it in some mater. (Stephan Kulow)
	# I used much code from Janos Farkas

	in my configure.in self-generated by KDevelop. Why an automated script that 
generates configure.in is going to add to every package this kind of 
comments?

	Well, that was my question... is there a way (a console command) to 
auto-generate acinclude.m4 and configure.in? (I suppose that acinclude.m4 
won't change, and I can copy that), but in that case, how can I generate 
configure.in?

Bye and thanks,
Rafael Fernández López.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-user] [OT] AUTOTOOLS

[Rafael Fernández López]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Oh, another thing that I didn't tell you:

	I'm an order maniac. When I start a project, my src directory has lots of 
subdirectories like 'base', 'gui'... and so on. I've seen that is almost a 
MUST to keep ALL *.UI FILES (from QT) in 'src' (at least KDevelop wants it).

	That is one of the reasons because I would like to write my own Makefile.am. 
But lots of questions came to my mind, like if I have something like:

myproject
        src
            gui
            base
            sounds
            [...]

	And my objective is only an executable (no .so...) is it necessary to go on 
creating *.la files for each directory (and portion of code) to get them 
linked at the end of the build process?

	I had some vtable errors from GCC that I had never had before (because before 
I used to write my own Makefiles) [no autotools].

Bye and thanks again,
Rafael Fernández López.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-user] [OT] AUTOTOOLS

[Zac Slade]

On Sunday 19 February 2006 18:32, Rafael Fernández López wrote:
> 	That is one of the reasons because I would like to write my own
> Makefile.am. But lots of questions came to my mind, like if I have
> something like:
>
> myproject
>         src
>             gui
>             base
>             sounds
>             [...]
>
> 	And my objective is only an executable (no .so...) is it necessary to go
> on creating *.la files for each directory (and portion of code) to get them
> linked at the end of the build process?
I'm not sure what you mean.  As a matter of fact your entire question is 
strange.  If you wnat to use autoconf/automake and don't want to use KDevelop 
then you are going to have to read the info pages for autoconf and automake.  
You will also need to find out what the m4 tests are for QT versions and 
kdelibs versions if you need that sort of dependency.  Makefile.am is only  
part of the puzzle here.

Your above section here doesn't make much sense either.  If you don't want to 
build libraries in your subdirs you don't have to.  You can build all the 
object files and then link them all together at the end of the build process.  
If you are creating a custom Makefile you can do whatever you please.

> 	I had some vtable errors from GCC that I had never had before (because
> before I used to write my own Makefiles) [no autotools].
What sort of vtable issues?  A little more information and a clearer statement 
of what you are trying to do would be very helpful.
-- 
Zac Slade

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] [OT] AUTOTOOLS

[Rafael Fernández López]

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

	Sorry but my english got worst (you know, 'if you don't use it, you lose 
it').

	I'll start again and maybe you'll understand me better: My problem is that 
I've been downloading some QT apps (KDE apps) to know how autotools code is 
written (I read the manual, but I need some practising or reading code). All 
'big' apps that could have some strange structure (like amaroK) that I've 
downloaded have been written through KDevelop help, and I don't want an 
automatic Makefile. I'll use IDE's when I know how to write it by my own.

	So, as I've seen, KDevelop copies all files (*.cpp, *.h and *.ui) to src 
path. Well, I'm pretty organized, and I like to have src/gui for *.ui files 
for example. All Makefile.am that I've seen suppose that all sources and *.ui 
files are in src, so they have something like:

bin_PROGRAMS = amarokapp

SUBDIRS = \
    amarokcore \
    $(SQLITE_SUBDIR) \
    analyzers \
    [...]


INCLUDES = \
    -I$(top_builddir)/amarok/src/amarokcore \
    [...]

amarokapp_SOURCES = \
    Options1.ui \
    Options2.ui \
    Options4.ui \
    Options5.ui \
    Options7.ui \
    Options8.ui \
    actionclasses.cpp \
    app.cpp \
    [...]

METASOURCES = \
    AUTO

	Well, in this case it's pretty easy, because all necessary files for building 
amaroK are on src.

	My question is: If I have a path like src, and inside it I have another 
directory called gui. (src/gui), then Makefile.am inside src/gui should be 
like this?

noinst_LTLIBRARIES = \
    whatever.la

noinst_HEADERS = \
    header1.h \
    header2.h

whatever_la_SOURCES = \
    main.cpp \

METASOURCES = \
    AUTO

	With noinst, because my objective is an unique executable file, and no 
libraries. Would that be correct?

	My problem is that it seems that there is no trouble in compiling process, 
but it seems that when it is going to link it fails, and it throws me some 
vtable failures (if you want I can write them here, but I've got some and 
different, because I've been changing my test code depending on what errors I 
have been getting).

Thank you very much,
Rafael Fernández López.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]