> Op 28 feb. 2015, om 11:04 heeft Siarhei Siamashka > <[email protected]> het volgende geschreven: > > 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.
KDE is a good example, nearly every module needs to compile something and run it to be able to compile itself further. Why use a 5 line shell script to generate something when you can use a 100 lines QT? > 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? Hardcoded entries to /usr/include and picking the first available header is pretty much par for the course. > >> 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? For sunxi-tools: simple makefile with a working 'make install DESTDIR=/path/foo'. I'm not sure if autotools it worth the work, but that would be my other recommendation. I suspect that sunxi-tools is simple enough to not need crazy cmake stuff, so I could live with that as well. Almost all of the new buildsystems try too hard to be not-autotools and throw away the useful features. I've not actually seen arguments against autotools in this thread, only "we should use $weird buildsystem because it fits with our non-prescription glasses and curly moustaches!" type of arguments. So: what are the technical arguments against: 1) Makefile with working make install 2) autotools regards, Koen > > -- > 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.
