[gtkada] improvements to the GtkAda build system

Arnaud Charlet charlet at adacore.com
Mon Feb 28 08:41:31 CET 2011


> You mean a log message to be provided to Subversion?

Yes.

> OK. How about these?
> · Add the Debuginfo build type, to build production libraries but include
> debugging information.
> · Link sublibraries to the main library.
> · Add an option to disable building of static libraries.
> · Improve the configuration help text to clarify what --enable-shared
> does.

A bit terse compared to GNU coding standard (whcih requires listing files and
functions/variables modified), and in addition, we want to
explain the "why" in these changelogs as per GtkAda/AdaCore coding
standard.

> Those patches did apply to the trunk when I sent them. An hour later, two of
> them no longer did. :-) I'm attaching updated patches.

Strange, I'm pretty sure I saw changes that wouldn't apply *before* these
changes when I reviewed them.

> > I believe the same can be achieved on the command line already: use
> > --enable-build=Debug at configure time
> > and then use
> > make GNATMAKE="gnatmake -O2 -gnatn"
> > 
> > You'll get -g and no strip as you need, and -O2 -gnatn if you want full
> > optimization, achieving basically the same effect, with no patch.
> 
> I'd also get -gnatwae -gnatay. If my memory serves me, it was -gnatwae that
> caused the build to fail when GCC in Fedora was upgraded to 4.5 and some new
> warning was introduced. That was what caused me to stop using the Debug mode
> and implement the Debuginfo mode.

Similarly you could add -gnatws or -gnatwn to the above command if this is
causing trouble:

make GNATMAKE="gnatmake -O2 -gnatn -gnatws"

> If I don't keep the Debuginfo mode, I think I prefer to configure as
> Production and add -g on the command line.

You would still get a call to strip in this case though, but any of the two
above option seems sufficient, so I'd prefer indeed not introducing another
hybrid mode, which may cause maintenance burden in the long term.

> The linking patch adds the missing DT_NEEDED entry to the sublibraries,
> which
> in turn causes the RPM subpackages to depend on the main package as they
> should.

Understood, thanks for the clarification.

> On the other hand, both libgtkada and the sublibraries contain a lot of
> unnecessary DT_NEEDED entries for libraries that they don't actually use.
> Those are added by a long list of linker parameters emitted by the command
> "pkg-config gtk+-2.0 --libs". This should probably also be addressed. I
> think
> the linker option --as-needed could be used, but I don't have a patch for that
> yet. This linking patch is at least a start.

Well, --as-needed is GNU ld specific so you cannot add it unconditionally,
and pkg-config is the standard way to link with Gtk+, so if there's something
to fix there, it should be in pkg-config --libs for gtk+-2.0 IMO.

> It's not really redundant but I agree that it sounds funny. How about writing
> "preselected" instead of "installation default"? Something like this
> maybe:
> 
> "Build shared libraries if supported on the target and make them
> preselected
> in project files. (By default static libraries are preselected when both
> kinds
> are built.)"

Looks OK to me.

Arno



More information about the gtkada mailing list