orbitcpp-list

[orbitcpp-list] Build issues and questions

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

Some build issues and questions...

        1. The current build overwrites the user variables CFLAGS and
           CXXFLAGS. Generally, you want to use the automake variables
           AM_CFLAGS and AM_CXXFLAGS for compiler options that should be
           provided by the build scripts. But... the options that the
           build is putting in CFLAGS and CXXFLAGS ("-g -O0") are the
           kind of options that the user should provide. I have fixed
           this and I can provide a patch.
        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.
        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?
        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?
        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.

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

Re: [orbitcpp-list] Build issues and questions

[Sam C. <sa...@to...>]

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.

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. :)

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

>         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. I think making
an additional configure script just for the compiler is a bad idea.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key ID:       DE89C75C,  available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

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

Re: [orbitcpp-list] Build issues and questions

[Sam C. <sa...@to...>]

Braden,

It's been a while since we last discussed ORBit-C++. Are you still
interested in helping out? I have more time to work on it now.

Braden McDaniel <br...@en...> wrote:
> 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.

I've thought about this a bit, and I now agree that a seperate configure
script for the orbit-idl compiler plugin would be useful.

The main reason I didn't want one before is additional complexity, but I
see it as necessary now.

There is also a second problem which it would allow us to solve: The
compiler plugin library should be a .so file with no versioning and no
symlinks, and the soname should match the filename.

I've merged your other patches (RPM spec file, "make distclean" fix)
into the CVS repository. Feel free to send more for building the compiler
component with a seperate configure script, the other build problems
you've mentioned, or anything else you have fixed.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key ID:       DE89C75C,  available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Build issues and questions

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

On Sat, 2001-12-08 at 01:15, Sam Couter wrote:
> Braden,
> 
> It's been a while since we last discussed ORBit-C++. Are you still
> interested in helping out? I have more time to work on it now.

Yes, but now I'm afraid I'll have to put you off for a few weeks. :-)
I've just relocated from Miami to Washington, DC, and things are a bit
hectic.

> Braden McDaniel <br...@en...> wrote:
> > 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.
> 
> I've thought about this a bit, and I now agree that a seperate configure
> script for the orbit-idl compiler plugin would be useful.
> 
> The main reason I didn't want one before is additional complexity, but I
> see it as necessary now.
> 
> There is also a second problem which it would allow us to solve: The
> compiler plugin library should be a .so file with no versioning and no
> symlinks, and the soname should match the filename.

Yep. I actually went ahead and did this. It works well. When I get a
chance, it shouldn't take me too long to get the patch together.

> I've merged your other patches (RPM spec file, "make distclean" fix)
> into the CVS repository. Feel free to send more for building the compiler
> component with a seperate configure script, the other build problems
> you've mentioned, or anything else you have fixed.

I'd be happy to... But it'll probably have to wait until I've moved into
a new apartment. :-)

Braden

Re: [orbitcpp-list] Build issues and questions

[Sam C. <sa...@to...>]

Braden McDaniel <br...@en...> wrote:
> Yes, but now I'm afraid I'll have to put you off for a few weeks. :-)

Hehehe... Serves me right. :)

> Yep. I actually went ahead and did this. It works well. When I get a
> chance, it shouldn't take me too long to get the patch together.

Excellent.

> I'd be happy to... But it'll probably have to wait until I've moved into
> a new apartment. :-)

No problem.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key ID:       DE89C75C,  available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C