From kdevelop Tue Apr 11 22:03:15 2000 From: "W. Tasin" Date: Tue, 11 Apr 2000 22:03:15 +0000 To: kdevelop Subject: Re: [Fwd: ACE/TAO with KDevelop?] X-MARC-Message: https://marc.info/?l=kdevelop&m=95549077532101 "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 ma= kefile > > > which knows how to build my CORBA server object. The CORBA server o= bject > > > 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 librarie= s, > > > libtao.so and liborbsvcs.so, so the main app will have to link thos= e as > > > well. Any source file in the main app that references the CORBA ser= ver > > > object has a whole slew of include files, compile flags, and link f= lags 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 =3D "). Maybe you don=B4t need all the *_la_LIBADDS=3D so you can also remove the= unneccessary stuff, but it isn=B4t 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: _LDADDS =3D /lib.la ......... (e. g. kde_cm_LDADDS =3D tao/libtao.la ....... ) For another project which should use your library you have to append -l (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=3D") 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=B4t want to break the platform independence of th= e 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 t= o > > incorporate my customizations into any Makefiles that it generates. W= hile I > > understand the value of automake, autoconf, and configure, does this = require > > that we sacrifice the ability to exercise precise control over the bu= ild > > process? > > > > I greatly appreciate your help, and the work of the KDevelop team, > > > > Don Dade > > ddade@digitalstatecraft.com Hope this mail helps... even if there are many answers in a compressed form in it :-) Ciao Walter -- = The KDevelop project: tasin@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----------: