On Wed, Sep 22, 2010 at 4:20 AM, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
Hello Michael,
I'm looking into "branding" changes needed for a Linaro GDB release. So far I've made the following changes:
- Set default PKGVERSION to "Linaro GDB" instead of "GDB"
- Set default BUGURL to "http://bugs.launchpad.net/gdb-linaro/" instead of
"http://www.gnu.org/software/gdb/bugs/"
- Set version number according to Linaro version scheme
- Update release script to generate tarballs/directories named
"gdb-linaro-$VERSION" instead of "gdb-$VERSION".
As a result, the default GDB startup output now reads:
GNU gdb (Linaro GDB) 7.2-2010.10-0 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: http://bugs.launchpad.net/gdb-linaro/.
Do you agree that this is the way we should go? Have I overlooked anything?
These all sound good. Andrew, are there any other changes you can think of?
As a related question, the generated files in a standard GDB 7.2 release seem to have been built on a relatively old system (RHEL 4 ?), which is visible through the versions of tools like bison, flex, texinfo, and gettext used to build those files. When building our Linaro GDB release tarballs, should we:
- just use the tools as installed on a recent build system (say, Ubuntu
Lucid), or
- attempt to rebuild the release with the exact same set of tools used for
the GDB 7.2 release?
We should use the tools that come with Lucid. This does cause a bigger diff but is easier to reproduce and less of a maintenance problem.
I'm not happy with generated files being checked in, but we have to do that to be drop-in replacement for the upstream GDB.
If it's straight forward then I'd like to avoid checking in the generated files if the change is only due to tool changes. We will regenerate everything as part of the release process but it would be nice to keep the branch clean.
-- Michael