01.11.2011 20:11, KP Kirchdoerfer пишет: > Am Dienstag, 1. November 2011, 00:06:50 schrieb Andrew: >> Hi all again. >> Now I finished porting of basic package set to new toolchain - all that >> are needed for building kernel, root.lrp, initrd and moddb, to look how >> it's working into VM. >> Minimal system booted OK; also I saw that syslog-ng in new environment >> is linked with libpthread - so I included in into root.lrp (it is just >> near 80k). >> I changed optmization from -Os to -O2 - it causes some size growth, but >> not catastrophic (+15..20% of user-level app size average); IMHO after >> initrd/moddb cleanup system still will be usable on 16M devices (default >> i686 minimal set now requires exact 14MB RAM in VM with one e1000 NIC - >> comparable to 4.x branch). >> >> So now there are such tasks: >> 1) Add 'arch' command line key for buildtool.pl/buildpackage.pl >> 2) Add 'template' support for kernel-related package that can have >> multiple subarchs (moddb and so on) >> 3) Port other 100+ packages into new toolchain (this is mostly trivial >> task, except some exceptions with poor makefile/configure); don't forget >> that ifenslave/vconfig now is present into busybox >> 4) Add 'arch' to .lrp and checking for corresponding .lrp arch and >> system arch on .lrp loading/updating, and 'noarch' special type for >> non-binary packages (scripts& etc) >> 5) Add uClibc++ into toolchain >> 6) Maybe other important things that I missed because I'm tired enough, >> and 7) Test toolchain/software assembly on different distros/platforms >> - I excluded all toolchain apps that should be present in any distro, >> like nasm/automake/bison (to simplify toolchain and to detect >> potentially poor/problematic code). > > Hi Andrew; > > I successfully tested the changes today, all seems to build well. > > I'd liked to start with test porting packages myself, but I'm not shure > what has to be changed for simple package like dnsmasq and how to test, if > everything went as expected. Just look if i is linked with uClibc, not system glibc. If yes - all is built OK. > But then I looked into the changes you've made for ppp and think we may sit > back and think a few days about the options we have. > > I want to explain my thoughts: > > The current buildtool has been adopted from early buildroot/buildtool > scripts for uClibc and hacked to work for our needs. > Over the years more cross-toolchains came up, and some a lot cleaner, than > our ones. > > I looked today again at buildroot (buildroot.org), which has been improved > a lot over the years, since Arne and Martin build our buildtool stuff. > And I compared esp. their ppp setup, which seems a lot easier to > understand, than what I find in BuC-next. And even it will have a steep > learning-curve to learn a new buildtool environment, it seems easier than > creating such intrusive makefiles patches as you did - at least for me. > And I don't know, how we can write a documentation about how to build a new > package, if it possibly requires such patches. Changes in ppp isn't too heavy - just update plugin's rp_pppoe version to 3.10 (which is now in building tree) and to remove missing library (libresolv) - that is for unknown reason isn't present as separate library and possible included into one of uClibc binaries. Other isn't changed from earlier version. You may look on more common cases - packages with 'true' configure script. They are assembled like on native system. Without need for heavy modifications, without pulling system libraries by mistake and so on. If developers didn't break cross-compilation by ugly hacks (like in dhcpd - which pulls full isc-bind and tries to build it on one of building steps). And I think that we'll clean many hacks from packages - at least, accel-pptp now is assembled in more clear way. > Maybe I do need just to work with the changes you made and get used to > build packages with toolchain, but then this is such a major change for > Bering-uClibc (in terms of effort *and* result), we may take the time to > think a bit more about our tool for the forthcoming years. > > Not a proposal, just a quick idea: it might be easier longterm to fork > again from buildroot and adjust it to our needs, instead of hacking a hack > once more. AFAIK David looked into OPenyoko(?), maybe he'll has something > to add about his findings... If somebody can move current infrastructure (.lrp creation, etc) to other building environment and it'll be enough useful and simple (not worse than current buildenv) - I haven't any votes against this. In any case, cleaned/ported packages can be moved to new building system easier. > Andrew; don't get me wrong, I really appreciate your work and commitment, I > just want to make shure that before we put that amount of work (rework 180+ > packages, rewrite a lot of documentation, doing all sort of tests....), > we'll take the time to discuss the options, needs etc. to get something > we'll have "fun" to work with, which can be "easy" enough to encourage new > developers, packagers... > > every opinion is welcome, thx for reading > kp > I also will be glad to hear opinions. But in any case, now building process looks more 'right' than earlier, and lot of magic tricks becomes unneeded.
P.S. I made some building system clean-up for more clear building process; I think that nothing is broken. You can look at quagga - almost in that way all 'good' packages expected to be built. ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
