[Fwd: ACE/TAO with KDevelop?]

[W. Tasin]

Ralf Nolden wrote:
> 
Hi all,

I will try to do this...
these are really complex questions and I don´t think it could be solved
in one mail.
maybe there are also many possibilities to solve your problem and I´m
sure that I will not answer all.

> Could someone answer this mail ?  I could do it but I´m really short on
> time this week and I guess he wants an answer within days.
> Volunteers ?
> 
> ;-)
> 
> Ralf
> 
> PS: send answers via private email, his question was on a kde newsgroup
> and he obviously isn´t subscribed to kdevelop@ mailinglists
> 
> Donald Dade wrote:

> >
> > >Hi Don,
> > >
> > >could you contact us about the issue and what´s the problem ? ( I don´t
> > >know what ACE and TAO are ;-)
> > >
> > >Ralf
> >
> > Hi Ralf, thank you for getting back to me, and so quickly too :).
> >
> > Well, ACE is the Adaptive Communication Environment, which is a highly
> > portable framework for socket programming. TAO is a CORBA implementation
> > written using ACE, and so is itself highly portable. It is quickly becoming
> > the implementation of choice for Linux because it is under the GNU license,
> > and it is extremely well designed and implemented.
> >
> > The problem that I am having is that while I do not understand KDevelop's
> > project directory structure, nor how KDevelop manages the Makefile.am,
> > Makefile.in, and Makefile files.

Ok... first this question:
KDevelop´s project structure primarily leads on the directory structure
needed for automake/autoconf.
On the second hand there is created another subdirectory which has the
same name as the project, and this is KDevelop specific to simplify the
project handling (so "make" will be called from within this directory to
make only the stuff inside this directory (the "application" part of the
project)
so the whole stuff was easier to handle in the KDevelop 1.x project
management)
But returning to the question:
_Only_ Makefile.ams and configure.in will be patched by KDevelop.

If you want to setup own flags this should be done in one of these file
(either by KDevelop usage or manually depending on the problem you
have).
If you would change something in them, so you have to invoke certain
applications to get the "real" Makefiles (these tools are automatically
called by invoking "make Makefile.dist" or using KDevelop´s command 
[Build/Automake and autoconf] and by the "configure"-call):
Here a very very simply explaination of these tools:

1) aclocal
this creates from configure.in, acinclude.m4 and system specific *.m4
files an aclocal.m4 - a little bit like linking them together.
(aclocal.m4 then is necessary for the next tool-binaries)

2) autoheader
for your problem a secondary call. This tries to make a CONFIG_HEADER
template... if there is a AC_CONFIG_HEADER-call inside configure.in... 
Normally this is a AC_CONFIG_HEADER(config.h) call, so something like:

cat config.h.top acconfig.h (+ AC_(UN)DEFINE* calls inside aclocal.m4
and configure.in) config.h.bot > config.h.in

will be done.

3) automake:
this scans the project directory structure and makes for each
Makefile.am a platform independable Makefile.in.
The directories which have to be scanned are taken from configure.in
(see AC_OUTPUT macro call)

4) perl am_edit:
this "magic" call patches the Makefile.in´s for QT/KDE applications
(this has moc-support, po-support, some workarounds for automake bugs, 
etc.)
BTW: this call substitutes "automoc".

5) autoconf
this call makes a configure-script from configure.in and aclocal.m4

then at the end
6) configure
this call converts Makefile.in´s and the config.h.in (if present) to
platform dependent Makefiles and config.h.

So you can see, the only thing KDevelop makes is to patch
Makefile.am/configure.in (and you should also do so)... 
the rest will be created by automake/autoconf stuff.

> >
> > What I would like to do is the following: My project is called kde_cm. So I
> > have directories called ./kde_cm, ./kde_cm/kde_cm, and ./kde_cm/po. I would
> > like to have another directory ./kde_cm/tao that holds my custom makefile
> > which knows how to build my CORBA server object. The CORBA server object
> > will produce an object file that will have to be linked by the main KDE app
> > in the ./kde_cm/kde_cm directory, and it requires 2 shared libraries,
> > libtao.so and liborbsvcs.so, so the main app will have to link those as
> > well. Any source file in the main app that references the CORBA server
> > object has a whole slew of include files, compile flags, and link flags that
> > it needs.

I will answer these questions in another mail, because I still have to
check something.

For now:
Ok... KDevelop lacked for creation and usage of shared lib.
But I've done a maybe minimalistic, but as I hope a sofisticated, shared
library implementation, more about that in the next mail ;-).

> >
> > I suppose that I can change the Makefiles to force them to work, but
> > KDevelop can and will overwrite my changes the next time the Makefile is
> > generated. So my problem is that I do not know how to tell KDevelop to
> > incorporate my customizations into any Makefiles that it generates. While I
> > understand the value of automake, autoconf, and configure, does this require
> > that we sacrifice the ability to exercise precise control over the build
> > process?
> >
> > I greatly appreciate your help, and the work of the KDevelop team,
> >
> > Don Dade
> > ddade at digitalstatecraft.com

Ciao

Walter