On Wed, Apr 22, 2009 at 07:33:47AM +0200, Ralf Wildenhues wrote: > Hello, > > * JRS wrote on Wed, Apr 22, 2009 at 07:02:55AM CEST: > > I was setting up build infrastructure once again when it occurred to > > me, hmm, wouldn't it be nice if automake had default targets for > > installing symbols? > > > > For example, make install-syms could do objcopy --only-keep-debug on > > the binaries and libraries, and put the .debug files in > > /usr/lib/debug. > > What's the advantage over just installing binaries into $(bindir) > without stripping them? Non-brain-damaged systems won't load them from > the file anyway for normal execution.
I have two uses cases in mind: 1) Embedded systems development. Sometimes your dev board is the same as your shipping board, and the storage is limited and not replaceable. Some of these devices don't have network interfaces for NFS either. 2) For groups that release their own packages, shipping the debug symbols unconditionally in every download can translate into a significant amount of bandwidth. If the package is mainly used by users who don't know which end of the debugger is which, most of those downloaded symbol bits aren't going to get used and it might be more cost effective to just provide those packages separately. The counterargument to 2) is that whoever's on package duty should separate the debug information themselves, but then you have all the packagers reinventing the wheel instead of factoring out the necessary logic into autotools. In particular, I'm thinking of buildroot. I think adding automatic debug symbol generation to all the packages would be a large patch, whereas adding that feature via autotools instead would result in a smaller patch. > Also, objcopy is not portable to anything that doesn't have GNU > binutils. It was just an example. Other platforms would use otool or LINK, of course. > Just get the git tree here: > > git clone git://git.sv.gnu.org/automake.git > cd automake > ./bootstrap > > and then get hacking. README, tests/README contain information about > testing, the HACKING file contains information on what is requires for > patches to be applicable. And yes, we'd prefer full test exposure for > all new features. Ah, that was what I needed to have. Thanks.
