[Orca-dev] Re: ORCA build/installation [patches]

[Blair Zajac]

[cc-ing orca-dev to keep a copy of our conversation and to invite other 
contributors]

Andreas Beckmann wrote:
> Hi,
> 
> I'm using ORCA on a SunFire v20z running SuSE-Linux 9.1 (x86_64) with
> kernel 2.6.
> 
> While updating my packaging scripts etc. to the latest orca-snapshot, I
> created some patches and also found some problems:

Hi Andreas,

Thanks for the patches.

> 1.) orca-snapshot-r451.01.DESTDIR.patch
> Add $(DESTDIR) support to all install targets.

Committed in revision 452.

http://www.orcaware.com/pipermail/orca-checkins/2005-May/000311.html

> 2.) orca-snapshot-r451.03.create_missing_dirs.patch
> The installation of procallator forgets to create $(sysconfdir) before
> installing the config file.

Committed in revision 453.

http://www.orcaware.com/pipermail/orca-checkins/2005-May/000312.html

> 3.) orca-snapshot-r451.02.perl_mandir.patch
> Similar to the perl modules installed into $(libdir)/perl/, the
> corresponding manpages are installed into $(mandir)/man{1,3}/.
> Without this patch a manpage from ORCA's private copy of rrdtool is
> installed into /usr/share/man/man3/RRDs.3pm

This was actually a problem of the $(DESTDIR) being prefixed to the 
files that I don't want installed, because Orca's private copy of these 
Perl modules should not install the manual pages, which may collide with 
already installed manual pages.  So everything but the required 
libraries are installed into $(srcdir_perl_install_rootdir),which is 
deliberately kept in the source directory.  So if you look at the change 
log for revision 452, you won't see $(DESTDIR) prepended to 
$(srcdir_perl_install_rootdir).

> 4.) UNRESOLVED: rrdtool FTBFS on x86_64
> The CFLAGS passed via ORCA_MAKE_DEFINES override the CFLAGS set in
> the rrdtool-* Makefiles which causes an omission of -fPIC and results in
> a linking error.
> I don't have a clean fix for this problem, sorry.

I'll think about this.

> 5.) Shouldn't all the Makefile targets depend on Makefile.in and
> $(topdir)/config.status ? So they get rebuilt after reconfiguration.

They already do depend upon Makefile.  But you raise a good point that 
they don't depend upon $(topdir)/config.status

The rules are also not pretty, as they look like this:

Makefile: Makefile.in
         cd ../.. && CONFIG_FILES=data_gatherers/procallator/Makefile 
./config.status

with the appropriate number of ..'s and the path in the CONFIG_FILES 
listed.  If there's a better way of doing this that isn't GNU make 
dependent, I'd be interested in hearing about it.

BTW, topdir is not defined in my autoconf.  Here are the ones that do exist.

@srcdir@
@abs_srcdir@
@top_srcdir@
@abs_top_srcdir@
@builddir@
@abs_builddir@
@top_builddir@
@abs_top_builddir@

> 6.) config/PerlHead1.in
> Is it possible to move the comment from the #!@PERL@ line to the
> next line, because it appears in the output of ps:
> 
>    ... /usr/bin/perl -w # -*- perl -*- /opt/orca/current/bin/orca ...

Well, the reason for it being there is so that XEmacs and possibly other 
editors load the correct mode to edit the file.  If you can come up with 
another way of handling this, let me know.

> 7.) lib/SE/
> Since this is only used by the orcallator (or did I miss something?),
> these files shouldn't be installed if orca has been configured with
> --disable-orcallator.

Patch welcome to add this change!

> Perhaps lib/SE/ should be moved to data_gatherers/orcallator/SE/?

Other packages beyond orcallator may depend on SE.  Also, there is now a 
$libdir/perl subdirectory, so having language directories in $libdir 
seems like a good idea.  But yes, it shouldn't be installed if 
--disable-orcallator is flagged.

> As soon as I find some time, I'll look over my procallator patches again
> (mainly kernel 2.6 support) and send them to you, too.

Thanks.  I got in contact with the procallator author and he said that 
he is going to re-license it as GPL and also has some 2.6 fixes in it. 
I'd rather not accept any patches on the non-GPL licensed version that 
is currently in the tree.

> 
> 
> Thanks for ORCA!

You're welcome!

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair at orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/consulting/