Re: [linux-sunxi] New sunxi-tools v1.3 release planning
On Sat, 2015-02-28 at 11:24 +0100, Koen Kooi wrote: > > What would be actually your suggestion? > > For sunxi-tools: simple makefile with a working 'make install > DESTDIR=/path/foo'. ...which installs not-too-generically named binaries, with that: ack from me too. WRT not-too-generically named: e.g. usb-boot and bootinfo are certainly too generic, so in Debian I add a sunxi- prefix. fel, fexc etc might be OK, but there's some potential for a clash (mostly due to them being quite short acronym fodder). I ended up prefixing them sunxi- in Debian for consistency with the other binaries. My preference would be for everything to be prefixed (perhaps unless it's not actually sunxi specific somehow and just happens to live in sunxi-tools). > 1) Makefile with working make install > 2) autotools That would be my order of preference too. I think the sunxi-tools build is simple enough that just supporting and correctly using $(HOSTCC) and $(CROSS_COMPILE)$(CC) (and AS, LD etc) would be sufficient, even for the sort of canadian cross-compiles discussed elsewhere in this thread, without needing to go to full autotools (but I could live with the latter). WRT needing a cross compiler, I think all which is really needed for lots of the useful stuff is a cross binutils (specifically $(CROSS_COMPILE)$(AS)). Currently the build uses gcc to drive as+ld for building .S into .elf, but I think it could use as+ld directly without much effort. There are some trivial .c programs (fel-sdboot.c) which could easily be rewritten in asm. I think there would still be one or two things which are C which couldn't be done this way, but this would get far better coverage in distro builds with very little effort. The reason I mention cross-gcc vs cross-binutils is that for distros providing a cross binutils is generally pretty trivial, it's only once you get into cross-gcc and "which libc do I use" type questions that things get tricky and tend to stagnate. FWIW Debian has a cross binutils package targeting arm already and will ship it in the next release (Jessie). BTW, looking at the current makefiles it seems that we pass a load of options when building .S files which only make sense when compiling from .c (e.g. -Wno-format-nonliteral etc). Ian. -- 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.
Re: [linux-sunxi] New sunxi-tools v1.3 release planning
> Op 28 feb. 2015, om 11:04 heeft Siarhei Siamashka > het volgende geschreven: > > On Sun, 22 Feb 2015 20:56:35 +0100 > Koen Kooi wrote: > >> >>> Op 22 feb. 2015, om 18:46 heeft Siarhei Siamashka >>> het volgende geschreven: >>> >>> On Sun, 22 Feb 2015 11:02:49 +0100 >>> Diego Roversi wrote: >>> On Sat, 21 Feb 2015 15:51:19 +0200 Siarhei Siamashka 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] New sunxi-tools v1.3 release planning
On Sun, 22 Feb 2015 20:56:35 +0100 Koen Kooi wrote: > > > Op 22 feb. 2015, om 18:46 heeft Siarhei Siamashka > > het volgende geschreven: > > > > On Sun, 22 Feb 2015 11:02:49 +0100 > > Diego Roversi wrote: > > > >> On Sat, 21 Feb 2015 15:51:19 +0200 > >> Siarhei Siamashka 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] New sunxi-tools v1.3 release planning
On 22 February 2015 at 20:58, Koen Kooi wrote: > >> Op 22 feb. 2015, om 14:56 heeft Michal Suchanek het >> volgende geschreven: >> >> On 22 February 2015 at 11:02, Diego Roversi wrote: >>> On Sat, 21 Feb 2015 15:51:19 +0200 >>> Siarhei Siamashka 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. BTW I think that adding autotools >>> support to trivial C program can be considere bike shedding (ihmo). >> >> And any self-respecting distro has build time dependency handling so >> you don't really have to detect libraries since you will have them >> installed by the package build system. > > Taking that argument to its logical conclusion means that autotools, > pkg-config and friends aren't needed anymore because the distro will solve it > for you. > Yes, for a simple project. It's not like sunxi-tools support multiple versions of libusb so we can just assume the user installed an usable version and at most use pkg-config to determine the flags needed to compile with it. And that's about the only dependency there is. In distro packages the cross-compiled binary can be just built natively on the arch it is for. For manual cross-compile there can be special target which the distro will not use. The build systems are all horrible and broken by design. And every time they make a new one to fix a flaw in one of the existing ones they get something else completely wrong. I'm sure you would find tons of articles on the inherent flaws of design of make (any variant), autotools, cmake, ant, rake, scons or anything else you can point your finger at with the possible exception of systems that are too new for the articles to crop up. Thanks Michal -- 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.
Re: [linux-sunxi] New sunxi-tools v1.3 release planning
> Op 22 feb. 2015, om 14:56 heeft Michal Suchanek het > volgende geschreven: > > On 22 February 2015 at 11:02, Diego Roversi wrote: >> On Sat, 21 Feb 2015 15:51:19 +0200 >> Siarhei Siamashka 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. BTW I think that adding autotools >> support to trivial C program can be considere bike shedding (ihmo). > > And any self-respecting distro has build time dependency handling so > you don't really have to detect libraries since you will have them > installed by the package build system. Taking that argument to its logical conclusion means that autotools, pkg-config and friends aren't needed anymore because the distro will solve it for you. -- 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.
Re: [linux-sunxi] New sunxi-tools v1.3 release planning
> Op 22 feb. 2015, om 18:46 heeft Siarhei Siamashka > het volgende geschreven: > > On Sun, 22 Feb 2015 11:02:49 +0100 > Diego Roversi wrote: > >> On Sat, 21 Feb 2015 15:51:19 +0200 >> Siarhei Siamashka 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. Pretty much all the FindFoo method are broken by design and completely unfit for cross compilation or sysroot usage. 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. regards, Koen -- 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.
Re: [linux-sunxi] New sunxi-tools v1.3 release planning
On Sun, 22 Feb 2015 11:02:49 +0100 Diego Roversi wrote: > On Sat, 21 Feb 2015 15:51:19 +0200 > Siarhei Siamashka 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] New sunxi-tools v1.3 release planning
On 22 February 2015 at 11:02, Diego Roversi wrote: > On Sat, 21 Feb 2015 15:51:19 +0200 > Siarhei Siamashka 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. BTW I think that adding autotools support to > trivial C program can be considere bike shedding (ihmo). And any self-respecting distro has build time dependency handling so you don't really have to detect libraries since you will have them installed by the package build system. Everything except meminfo should work natively. I think meminfo should be built statically on arm as architecture:all package so you don't have to deal with cross-compiling at all. On the other hand, detecting a cross-compiler is a must if it is used because there does not seem to be a standard binary. eg. there is a 'gcc' package which installs some symlinks for the curreent version of gcc so that you can just run 'gcc' to compile C source but the situation for cross-compiler packages is less than ideal. Thanks Michal -- 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.
Re: [linux-sunxi] New sunxi-tools v1.3 release planning
On Sat, 21 Feb 2015 15:51:19 +0200 Siarhei Siamashka 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. BTW I think that adding autotools support to trivial C program can be considere bike shedding (ihmo). -- Diego Roversi -- 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.
[linux-sunxi] New sunxi-tools v1.3 release planning
Hello, The sunxi-tools repository contains the 'fel' utility, which allows booting Allwinner devices over USB using the FEL mode. The upcoming u-boot v2015.04 is going to use the new 'spl' command, recently added to the 'fel' tool. As I can see, sunxi-tools is packaged at least in debian and fedora: https://packages.debian.org/sid/sunxi-tools https://admin.fedoraproject.org/pkgdb/package/sunxi-tools/ So it might make sense to prepare the new sunxi-tools release v1.3 and let the linux distributions pick it up eventually. 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). Still it would be nice to fit the build into the standard sequence: autogen configure make make install Where the 'autogen' script is necessary to run after cloning from git, but is optional when building the sources after extracting them from tarballs. Maybe we can handle the arm crosscompiler stuff in the 'autogen' step? And then the rest of the build would only need just a normal C compiler. Does anyone have any experience properly taking care of things like this? Any better ideas? PS. Appears that the new 'spl' command does not quite work on A13 hardware, because the BROM on A13 stores the MMU address translation tables at 0x8000 (instead of the secure SRAM on A10 and A20). I'm working on a fix for this issue. -- 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.
