[Fwd: ACE/TAO with KDevelop?]

[W. Tasin]

"W. Tasin" wrote:
> > > 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 AND as I hope a sofisticated, shared
> library implementation, more about that in the next mail ;-).
> 


Back to the questions:
1) ./kde_cm/tao

For KDevelop usage, it isn't a good idea to use this in that way.
(Apart from writing own Makefiles in a custom projects -

but the best solution would be always to create a Makefile.am to include
this to
the automake/autoconf stuff, because the great advantage would be the
platform
independance.
This may be a harder work, but it would be worth to do.)

I suggest to create kde_cm/kde_cm/tao instead of kde_cm/tao or to create
another project like a test-app for the shared lib calls and as a
subdirectory to this test-app the tao-shared-lib itselfs.

Reasons:
- As described in the last mail a simple "make" would be called inside
"kde_cm/kde_cm" and not in "kde_cm".
Only "Rebuild All" and "Clean/Rebuild All" would be called from
"kde_cm".
(Even apart from custom projects... but if you would decide for a
"normal project" you would get more advantages from the
ability/functionality of KDevelop)

- The dependencies tracking within KDevelop for this shared lib would be
more
complicated.

2) shared libraries creation

The following text considers the actual CVS version of KDevelop, so
don't try it with 1.1...
it will be possible only in snapshots (younger than 04/10/2000) and of
course later in
KDevelop 1.2.

Now the creation of a shared library will be done with the RFV.

A static (and non-installed) library is automatically created by adding
a subdirectory in the source directory of your project (in your case a
subdirectory in kde_cm/kde_cm)

To add a folder (like "tao") you can use also the RFV and open the
pop-up menu of a directory folder in this tree.
If a file was added to this directory _and_ to the project (by
"File/New" inside this directory or adding existing files to the project
or again using the popup menu: item "New File"), a Makefile.am will also
be created in this named subdirectory.
At this point the Makefile.am is - as already said - for creating a
non-installed-static lib. 

Now you can click again on this folder icon in the tree an select
"change to shared library" so this Makefile.am is changed to create a
shared library instead.
The old (or better: the last) Makefile.am is backupped as
Makefile.am.old.

In general you have to patch the Makefile.am manually to declare the
include files, which have to be installed with the shared lib and
describe the functionality of it.
This should be done outside the KDevelop specific part of this
Makefile.am (make variable: "include_HEADERS = ").
Maybe you don´t need all the *_la_LIBADDS= so you can also remove the
unneccessary stuff, but it isn´t obligatory.

3) shared library usage

For the project, which contains the shared lib all should be already
done.
In the parent directory's Makefile.am you should see following line:
<projectname>_LDADDS = <shared lib dir>/lib<libname>.la .........
(e. g.
kde_cm_LDADDS = tao/libtao.la .......
)


For another project which should use your library you have to append
-l<libname> (e. g. -ltao)
to "additional libraries" in the "project options/linker options"
(of course the library has to be installed, too)

This only works proper if the library will be install in an directory
which is scanned and tested by the configure script (the need of a -L
linker flag).
Like for KDE applications configure searches for the kde-lib directory
and adds the found path to the Makefile.
(You can see which pathes are automatically inserted by looking inside a
created Makefile and search for the variable "all_libraries=")

For libraries which will be installed in another directory (which are
not searched by the configure script), all this is getting more
complicated (if you don´t want to break the platform independence of the
autoconf/automake stuff).


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

Hope this mail helps... even if there are many answers in a compressed
form in it :-)

Ciao

Walter
-- 
The KDevelop project: tasin at kdevelop.de [www.kdevelop.org]
--
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>