Re: [orbitcpp-list] Build issues and questions

[Braden M. <br...@en...>]

On Sun, 2001-10-21 at 21:31, Sam Couter wrote:
> Braden McDaniel <br...@en...> wrote:
> >         1. The current build overwrites the user variables CFLAGS and
> >            CXXFLAGS. [ ... ] I have fixed
> >            this and I can provide a patch.
> 
> Yes please. Use the Patch Manager at SourceForge.
> 
> >         2. The build system winds up redundantly defining some
> >            variables, and automake 1.5 spews warnings as a result. I
> >            have fixed this and I can provide a patch.
> 
> Yes please. Use the Patch Manager at SourceForge.

Will do.

> I'm currently finishing the final year of my university degree, so I
> won't be able to look at these patches for a few weeks, but after that
> I'll have all the time in the world. :)

Since these fixes touch a lot of the same files, it will be much easier
for me to create sane patches once the outstanding issues for which I've
provided fixes have been addressed. (I could just send you a big patch
that does a bunch of different things, but I know I don't like it much
when people do that to me. :-) So I will probably hold off on submitting
more patches for now.

> >         3. The project does the exact opposite of what the libtool
> >            documentation recommends, and ties it's package version
> >            number to the library version number. How come?
> 
> No idea. That's how it was before I got involved. It should probably be
> fixed.
>
> >         4. A number of the tests build with "-static" in CXXFLAGS.
> >            AFAICT, this is a linker option, so it should go in LDFLAGS.
> >            But why is it being used?
> 
> No idea, and it probably shouldn't be used.

Okay. I'll provide patches for these issues, too.

> >         5. The build currently creates and installs a static library for
> >            the IDL compiler. Unless I'm missing something, this is
> >            completely useless. I think I can fix this, but I think it
> >            would involved creating an additional configure script just
> >            for the compiler. This script would be called by the main
> >            configure script (see AC_CONFIG_SUBDIRS). I'd be happy to
> >            work on this, but first I wanted to make sure there's
> >            interest in such a change.
> 
> It is useless, as it's a dynamically loaded plugin for orbit-idl. It's
> never linked against directly.
> 
> But it doesn't cost much to build the static version, so don't put too
> much effort into making it not build the static version.

It costs about twice as much, timewise, as it would just to build the
shared module. (And here, at least, the compiler doesn't exactly zip
through the orbitcpp sources.)

> I think making
> an additional configure script just for the compiler is a bad idea.

Why?

The reason this would be necessary is that libtool doesn't provide a
means to selectively build shared/static libs on a per-library basis.
This selection is done per configure script.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>