[tao-users] include folder made by MAKEFILE's install option
Diego Susa
I'm not using the PRF because I have no "problems". Instead I have a few things I think I don't understand very well about TAO's "install" proccess,
I mean the "install" target of most makefiles.
I'm trying to build an ACE/TAO x.4.4 binary distribution for 2 other developers in my company to use. The idea is that they could just "copy" to their PCs a folder with all the exe's, dll's and lib's they need to compile and test some TAO projects.
Our current platform is WinXP, and we're using Borland & GNU tools.
In our previous distribution (x.4.1), I used to run:
make -f Makefile.bor -DINSTALL_DIR=e:\ACETAO
(provided e:\ACETAO is where I'm building the "binary distribution").
I've noticed that the layout of the generated "include" folder has changed somewhere between x.4.1 and the actual x.4.4
1) I've seen that /tao and /orbsvcs/orbsvcs are now placed inside a "top" level TAO folder (in my previous example it would be e:/ACETAO/include/TAO)... does anybody know why ?
2) I've also seen that all the code still has #include "tao/xxxx.h" instead of "TAO/tao/xxxx.h", which forces me to have 2 diferent "IncludePaths" in my projects:
e:\ACETAO\include (for all the #include "ace/xxxx.h" in ACE headers)
e:\ACETAO\include\TAO (for all the #include "tao/xxxx.h" in TAO headers)
As I've mentioned, in previous versions either /tao and /orbsvcs/orbsvcs "installed" includes where at my "distribution's" top level (e:/ACETAO/include).
So, with the actual layout every guy that used to have a "standard" ACETAO distribution would have to change all his projects... is this the way to go ? I'm sure I'm missing the "benefits" part of this changes... could someone place a hint ?
3) And the last question:
do those "install" targets exist in GNU makefiles ? or they're just for Borland (and/or other) tools ?
thanks in advance for any help !
Diego
J.T. Conklin
> I'm not using the PRF because I have no "problems". Instead I
> have a few things I think I don't understand very well about TAO's
> "install" proccess, I mean the "install" target of most makefiles.
Ok.
> I'm trying to build an ACE/TAO x.4.4 binary distribution for 2 other
> developers in my company to use. The idea is that they could just
> "copy" to their PCs a folder with all the exe's, dll's and lib's
> they need to compile and test some TAO projects. Our current
> platform is WinXP, and we're using Borland & GNU tools.
Ok. The borland and the automake configurations are the only ones I
know of that have "install" support. Both use the data from the MPC
files, so they both should be able to have usable installations. That
being said, I only use the automake install.
> In our previous distribution (x.4.1), I used to run: make -f
> Makefile.bor -DINSTALL_DIR=e:\ACETAO
> (provided e:\ACETAO is where I'm building the "binary distribution").
>
> I've noticed that the layout of the generated "include" folder has
> changed somewhere between x.4.1 and the actual x.4.4
>
> 1) I've seen that /tao and /orbsvcs/orbsvcs are now placed inside a
> "top" level TAO folder (in my previous example it would be
> e:/ACETAO/include/TAO)... does anybody know why ?
The automake installs its tree in:
${prefix}/bin -- ace/tao binaries
${prefix}/lib -- ace/tao libraries
${prefix}/include/ace -- ace headers
${prefix}/include/tao -- tao headers
${prefix}/include/orbsvcs -- tao orb services headers
With this layout, a single -I${prefix}/include is all that is
necessary to include any ACE/TAO header. Similarly, -L${prefix}/lib
is all that is necessary to link with any ACE/TAO library.
If the Borland build does not install it's headers/libraries in a
similar way, it could be a bug in the borland build infrastructure.
It would be great if you could investigate and provide whatever fixes
are necessary.
> 3) And the last question: do those "install" targets exist in GNU
> makefiles ? or they're just for Borland (and/or other) tools ?
I think it's just Borland and automake. The info is available in MPC
so other build types could support it. I've avoided adding it to the
GNUACE builds because I hope the automake build can eventually replace
it.
--jtc
--
J.T. Conklin
Diego Susa
I´ll try to investigate further, cause it seems something is broken in Borland Makefile's "install" option. I think that the "correct" installation's folder layout is that of automake's, as you described (besides I suspect it is much frequently tested than Borland's install).
In addition to what you've pointed about automake's installation of:
${prefix}/include/orbsvcs -- tao orb services headers
i've observed that Borland's installation creates these using 2 levels...
I mean, besides the "extra" /TAO folder, what I've got is:
${prefix}/include/TAO/orbsvcs/orbsvcs
Even when I "move" the includes folders to get rid of the extra /TAO folder, the ORB Services are organized:
${prefix}/include/orbsvcs/orbsvcs
And this layout prevents many TAO headers to compile,
for example CosNamingC.h which issues:
#include "orbsvcs/Naming/naming_export.h"
instead of:
#include "orbsvcs/orbsvcs/Naming/naming_export.h"
that could work, with the ...
I wonder if anyone is using Borland Makefile's "install" ...¿?
are they having these kind of problems ?
... maybe they just add as many Include/Lib Paths as needed to their projects ¿?
of course: if I add ${prefix}/include/TAO & ${prefix}/include/TAO/orbsvcs to my project's include path it could work, but I think the "right way" is to have only one "Include/Lib Path" as you said.
Thanks again,
your help was very useful :-)
Diego
J.T. Conklin
> I´ll try to investigate further, cause it seems something is broken
> in Borland Makefile's "install" option. I think that the "correct"
> installation's folder layout is that of automake's, as you described
> (besides I suspect it is much frequently tested than Borland's
> install).
I suspect the automake build is in better shape than the Borland
build. I have a vested interest in keeping the automake build,
including "make install", working. As far as I know, I have no
counterpart doing the same for the Borland builds. We would welcome
any changes to fix the Borland builds.
> In addition to what you've pointed about automake's installation of:
> ${prefix}/include/orbsvcs -- tao orb services headers
> i've observed that Borland's installation creates these using 2 levels...
> I mean, besides the "extra" /TAO folder, what I've got is:
> ${prefix}/include/TAO/orbsvcs/orbsvcs
The MPC generated Makefile.am files also install the orbsvcs headers
in ${prefix}/orbsvcs/orbsvcs. Since I have to tweak the results, I
have been fixing that by hand before I check them in. There is some
support in bin/MakeProjectCreator/modules/AutomakeWorkspaceHelper.pm
that is supposed to help fix this, but I haven't got around to make it
work. The Borland build needs something like this --- even more
desparately than the Automake build since the Borland makefiles are
not checked in (and take it from me, we don't want to go there).
FWIW, I suspect that the RMCast and TMCast headers are installed in
${prefix}/include/protocols/ace/RMCast and
${prefix}/include/protocols/ace/TMCast
instead of ${prefix}/ace/RMCast and ${prefix}/ace/TMCast as well.
> Even when I "move" the includes folders to get rid of the extra /TAO folder, the ORB Services are organized:
> ${prefix}/include/orbsvcs/orbsvcs
>
> And this layout prevents many TAO headers to compile, for example
> CosNamingC.h which issues:
> #include "orbsvcs/Naming/naming_export.h"
> instead of:
> #include "orbsvcs/orbsvcs/Naming/naming_export.h"
> that could work, with the ...
In previous TAO releases, some orbsvcs headers were #included with
"orbsvcs/...", others with "orbsvcs/orbsvcs/...", and some with no
prefix at all. We standardized on #include "orbsvcs/...", changing
things to "orbsvcs/orbsvcs/..." would be a step backwards. The
Borland build really needs to be changed to install the orbsvcs
headers in ${prefix}/orbsvcs just like the TAO headers.
--jtc
--
J.T. Conklin