Works like a charm. I probably should have specified in my ebuild remarks that I was simply very happy that building the big piece of the pie under src with only autotools, as shown in your note, and hence no ebuild involvement for that part of the pie is now supported.
Burt On Wed, Dec 28, 2016 at 10:25 AM, Damjan Marion (damarion) < damar...@cisco.com> wrote: > Dear Burt, > > > > On 28 Dec 2016, at 15:08, Burt Silverman <bur...@gmail.com> wrote: > > > > Hi Damjan, > > > > This looks really sweet. Finally, good riddance to ebuild. > > This change is not about getting a rid of ebuild, ebuild is still there. > Main goal here was to reduce number of packages and speed up build process. > Autotools cannot provide all features we have today in ebuild, and I > consider them as complementary. > > On other side if somebody wants to live without ebuild or use some other > build system like buildroot, bitbake, it can do it now much easier than > before. > > > Ebuild has a mix of some brilliant tricks and some useless irritations. > The brilliant tricks were primarily designed for the case of building a > slew of open source packages, rather than something like VPP that wishes to > be a single package (well, certainly vppinfra, svm, vlib, vppapigen, > vlib-api, vnet, and vpp wish to be a single package; I have not thought > about the rest.) > > > > Very clever that you came up with the idea of directory src -- allowing > you to keep most of the existing file paths when you converted > Makefile.am's to the new .am files. > > thanks. i was really focused on doing this change in the way that we > preserve as much as possible from existing Makefile.am. > > > I would have been too focused on converting path "x/x/..." to "x/..." > that I would never have thought of that. > > > > I would have ended up with a slower build system that is just a tad > closer to the pure automake direction and not pure Peter Miller the way > your system is. Well, I had worked with people at Ericcson IPI years ago > who liked to talk about Peter Miller's paper, but did not have the > competence to put together a nicely designed automake system using his > method. So I was always OK with "reasonably fast" pure automake. In other > words, their Makefile.am's were oblivit and ugly. > > > > I remember hearing that on humongous systems, a single Makefile could > mean latency if compiling a single file or if nothing had to be done, but I > am guessing that VPP is not that huge. Anyway, > > I think we are far far away of hitting that issue. On other side walking > trough SUBDIRs > is quite expensive, specially on systems with many cores, where it really > hurts where you go into > subdir to compile 3 files. > > > I look forward to pulling in the new build system when it is on master > and trying it. > > It is merged now…. > > >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
