On Tue, 24 Feb 2015 10:00:05 +0000 Ian Campbell <ijc+ub...@hellion.org.uk> wrote:
> On Tue, 2015-02-24 at 11:31 +0200, Siarhei Siamashka wrote: > > On Mon, 23 Feb 2015 13:12:32 +0000 > > Ian Campbell <ijc+ub...@hellion.org.uk> wrote: > > > > > On Sun, 2015-02-22 at 18:55 +0200, Siarhei Siamashka wrote: > > > > We might want to push sunxi-tools into more Linux distributions than > > > > just Debian and Fedora. And the maintainers of these distributions > > > > could be not very much impressed with the current quality of the > > > > sunxi-tools build process :) > > > > > > At least from my PoV as the Debian maintainer it's not so bad, mostly > > > because there isn't very much of it and it's pretty simple/basic. > > > > OK, thanks. So, I guess, this is one more vote in favour of keeping > > the existing makefile. > > FWIW I'm not opposed to a change to use autotools or whatever, I just > wanted to say don't do it just for my benefit or whatever. FWIW, making the distro maintainers' life easier was never my intention. But it's nice if this happens as a side effect. The real problem is: The distro maintainers are selecting the set of programs, which are getting installed as part of the sunxi-tools package. And also renaming these programs. Thanks to the lack of coordination between the sunxi-tools developers and different distro maintainers, the end result is about to become a mess and we can't provide clear instructions in the linux-sunxi wiki without distro-specific nuances. > > > The biggest issue from the Debian PoV is the binaries contained in the > > > release -- Debian cannot (or does not want to) ship any binary which is > > > not rebuilt as part of the package build, so I can't just use them. > > > > > > Rebuilding those binaries is hard because sadly cross-compilers are > > > still a WIP in Debian and ensuring that an Arch:all package is built on > > > a specific architecture (as someone in this thread suggested) is not > > > easily achieved. I could just do each upload containing armhf binaries > > > instead of relying on the buildd network, but that's just a workaround > > > and in any case I prefer to do source only uploads where possible. > > > > The 'fel' tool now contains some bits of ARM assembly, which are > > converted into annotated C arrays. This may be stepping into a gray > > area. > > Yes. Pragmatically given the way it's presented with the "source" in > comments right alongside I'd be fairly bullish about it being ok. > > Ultimately with Jessie being frozen the new version of the fel tool has > to be targeting Stretch (and jessie-backports once it opens) and if > there are no cross-compilers available by then I'd be quite > surprised/cross. > > > What is the Debian policy regarding the autogenerated 'configure' > > files? > > These days it is recommended best practice to regenerate them as part of > the package build and there are helper tools to do so (dh_autoconf et > al). Some large projects are bundling third-party libraries in their source tree for the sake of convenience. And support compiling with either the proper external libraries (if they are installed) or the bundled copies. The use of an ARM crosscompiler in the sunxi-tools can be handled in a pretty much similar way. It can be a configuration option of the build system to select whether to use the ARM crosscompiler or not. And if the ARM crosscompiler is to be used, then it can be either automatically detected, or provided as GCC triplet with another build system configuration option. There has been a bit of misunderstanding in this thread, and some people think that the crosscompilation is easy and already handled. But consider the following example. If somebody wants to build a powerpc package of sunxi-tools on an x86 box, then two crosscompilers are needed. One "powerpc-unknown-linux-gnu-" for compiling the tools themselves. And one "arm-linux-gnueabihf-" for compiling the ARM specific parts. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
