On Sun, 22 Feb 2015 20:56:35 +0100 Koen Kooi <[email protected]> wrote:
> > > Op 22 feb. 2015, om 18:46 heeft Siarhei Siamashka > > <[email protected]> het volgende geschreven: > > > > 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. > > For non-simple project cmakes is an abomination that should be avoided at all > costs. But it is used by KDE and some other non-simple projects already. It might be already too late to complain. Design wise, there are many abominations nowadays. With more than one of these being aggressively lobbied by their vocal supporters. But as long as I personally don't have to deal with all this crap and fallout myself (or unless I'm paid for doing this work), I just don't care much :-) > Pretty much all the FindFoo method are broken by design and > completely unfit for cross compilation or sysroot usage. Hmm. Does it really not work in practice? > Or the mis-feature where running cmake twice will ignore the > failures from the first run. The only positive thing I can say > about cmake is that is has the toolchain-file concept. As for the build systems in general, this one looks promising (especially for huge projects, because I remember the pain dealing with recompiling Firefox): https://jpakkane.github.io/meson/ http://video.fosdem.org/2014/H2215_Ferrer/Sunday/Introducing_the_Meson_build_system.webm However today CMake is supported everywhere and seems to provide the necessary features, at least on the surface. Even if it has some crap under the hood, that's none of my concern (it has to be handled between the CMake developers and distro maintainers). What would be actually your suggestion? -- 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.
