On Sun, 22 Feb 2015 11:02:49 +0100 Diego Roversi <[email protected]> wrote:
> On Sat, 21 Feb 2015 15:51:19 +0200 > Siarhei Siamashka <[email protected]> wrote: > > > Regarding packaging, there are some pull requests on github, which try > > to add autotools support. I have quickly looked at these patches and did > > not quite like them. They add autogenerated files to git, which is not a > > great idea. And also they don't seem to really solve the problem of the > > need to use two toolchains at once (part of the build needs to be done > > by the compiler from the host machine, and part of the build needs to > > be done by an arm crosscompiler). > > In debian, packages are compiled with a native compiler on a native > platform, so it's not really a problem. The current build process seems simple because the sunxi-tools git repository just contains the pre-compiled ARM binaries along with the sources. And this means that the end users don't need an ARM crosscompiler. However this also means that every commit to the sunxi-tools repository, which touches the ARM source code, also requires to update the pre-compiled ARM binaries. This is inconvenient and the sources may get out of sync with the binaries. Though if we don't plan to do much further development, then we can survive this minor inconvenience. > BTW I think that adding autotools support to trivial C program can be > considere bike shedding (ihmo). I myself tend to prefer CMAKE for very simple projects nowadays. It can take care of the pthreads portability issues, supports the "make install" target and can be easily imported into the Qt Creator IDE. The Linux distributions are already aware of CMAKE and know how to deal with it (regardless of whether they like it or not). In a way, I'm also doing some packaging work myself (for buildroot, which is used to build the initramfs for http://tinyurl.com/ptuaahd ): https://github.com/ssvb/buildroot/commit/0be088838d4df9c7e66b1918 Please note how trivially simple it is done for CMAKE. The autotools are also very nicely supported everywhere. The standard build systems are well known to both the end users and the distro maintainers. While ad-hoc makefiles tend to have rough edges and their own quirks. And now I also want to move my a10-meminfo patches from a10-dram-tools into sunxi-tools. Which happens to be already nicely packaged in the mainline buildroot. However the buildroot has to perform some extra gymnastics at the installation stage and does not install the 'meminfo' tool yet: http://git.buildroot.net/buildroot/tree/package/sunxi-tools/sunxi-tools.mk?id=2015.02-rc2 But more importantly, I have sent this e-mail to the mailing list just because we have pending pull requests in the sunxi-tools repository since 2013. And also a separate 'autotools' branch. Something needs to be formally done about this stuff. If we decide not to use autotools, then these pull requests can be just closed and the submitters told that their patches are not welcome :-) -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
