filesystem question for cross-devel tools
This is sort of long. Don't bother unless you care about what /usr's contents
look like, and/or you're desperate for reading material...
I've alluded in the past to my intention to package for Debian the cross
development tools we're using for AMD 29200 embedded systems development. I
care about this stuff because I'm working on an experimental payload module
for the AMSAT Phase-3D amateur satellite project. I am motivated, in part,
to do Debian packaging because most of the rest of my team is running one or
another version of Linux, and most are willing to switch to Debian if I do
this and it gets easier for them to track my tools work and stay up to date.
Historically, I've always built the gcc/binutils/gdb/<etc> pieces with a
'--prefix' of something like /usr/gnu or more recently /usr/cross, so that
the whole cross-development "mess" ends up in a tidy subtree. This, in part,
was because it was easy to clip the tree and hand it to someone else to
install... partly becuase there used to be naming conflicts before the Cygnus
and FSF folk got the cross-development prefixes working well... and partly
because it just seemed "messy" to interleave the pieces into the rest of the
filesystem. Besides, my cross-development tree is bigger than /usr/X11R6,
even with both the XFree86 *and* X-Inside servers loaded!
On the other hand, I'm trying to be a "good" Debian developer, and follow the
FSSTND. But, I hit the same "ugliness snag" that the /usr/i486-linuxaout
(sp?) discussion hits... I can either push the whole tree under something like
/usr/cross, or I can prefix to /usr and end up with a set of directories with
names like "/usr/a29k-amd-coff", "/usr/a29k-amd-udi", "/usr/go32", and so on.
This is because of the way the GNU tools form target-specific directores when
building cross-compilation tools.
For reference, here's what it looks like with two AMD 29k targets built with
a prefix of /usr/cross:
bdale@chunks:~: du /usr/cross
So, is this better or worse than if the above had the '/cross' token taken
out, and I set the prefix to '/usr'?
There are no longer any naming conflicts. The current contents of the
/usr/cross/bin directory, which would end up in /usr/bin if I use a /usr
prefix, are (other cross targets would create similar sets of files/links):
bdale@chunks:~: ls /usr/cross/bin
a29k-amd-coff-ar* a29k-amd-coff-objdump* a29k-amd-udi-ld*
a29k-amd-coff-as* a29k-amd-coff-ranlib* a29k-amd-udi-nm*
a29k-amd-coff-c++* a29k-amd-coff-size* a29k-amd-udi-objcopy*
a29k-amd-coff-c++filt* a29k-amd-coff-strings* a29k-amd-udi-objdump*
a29k-amd-coff-g++* a29k-amd-coff-strip* a29k-amd-udi-ranlib*
a29k-amd-coff-gasp* a29k-amd-udi-ar* a29k-amd-udi-size*
a29k-amd-coff-gcc* a29k-amd-udi-as* a29k-amd-udi-strings*
a29k-amd-coff-ld* a29k-amd-udi-c++filt* a29k-amd-udi-strip*
a29k-amd-coff-nm* a29k-amd-udi-gasp* protoize*
a29k-amd-coff-objcopy* a29k-amd-udi-gcc* unprotoize*
What I'm currently contemplating is one source package (all targets are built
in different object trees from one source tree), and a separate binary package
for each target. The uncompressed size of each binary package is going to be
on the order of 25-30meg, the uncompressed size of the source tree is about
50meg. I hope that doesn't cause anyone to panic...
Someone interested in other targets could grab just the source package, and
follow the "Notebook" file instructions I keep there to built a cross-gcc
environment for any supported target... the hard part (getting all the FSF
and Cygnus newlib pieces in one place, and forming the unified source tree)
would already be done.
Bruce also mentioned the notion that a 'cross-devel' subdirectory might want
or need to be added to the distribution tree for Debian to handle these and
other cross-development tools. I'm not opinionated about this at all, but I'd
like to know what "the right answer" is.
Comments, inputs, flames? I'm new enough to living on Linux that my opinions
aren't cast in stone yet. But I don't want to have to do this twice, so
knowing what "the troika" think the right answer is would help... If this
isn't something that can/should be part of the mainstream distribution, say so
too, because I suppose I could always privately publish the .deb's and achieve
the effect we want for our project...