FYI, I have recently started to use the buildx experimental feature in docker (>=19.03).
it looks interesting as it is designed on purpose for building multi-platform images, and manages to reuse the same dockerfile for as many platforms as supported by qemu (in theory). I'm not quite sure yet about the actual concerns of running emulation with jailed envs such as docker or the oldish chroot as opposed to x-compilation. I've tested for amd64/arm64 and works well. docker buildx build --platform linux/arm64,linux/amd64 -t myorg/vswitch -f Dockerfile . On Thu, Oct 31, 2019 at 10:48 PM Christian Hopps <cho...@chopps.org> wrote: > > > > On Oct 31, 2019, at 5:39 PM, Damjan Marion via Lists.Fd.Io <dmarion= > me....@lists.fd.io> wrote: > > > > > > > >> On 31 Oct 2019, at 21:41, Christian Hopps <cho...@chopps.org> wrote: > >> > >>> > >>> On Oct 31, 2019, at 4:03 PM, Damjan Marion via Lists.Fd.Io <dmarion= > me....@lists.fd.io> wrote: > >>> > >>> > >>> Let me clarify a bit more, as i can see that this still may be > confusing: > >>> > >>> 1) VPP is using cmake to build binaries and packages, all cmake > related stuff is in src/. > >>> > >>> 2) there is build-root/Makefile and files in build-data/* which are > part of old build system called ebuild > >>> - ebuild is very complex set of make scripts which have similar > functionality like buildroot, it was able to build kernel, toolchain , > userspace tools and libraries > >>> - today we don't use much of ebuild, it is just used to run VPP cmake > prioject in the right directory with he right set of command line arguments > >>> > >>> 3) Other Makefiles > >>> - top level makefile > >>> - external deps makefiles in build/external/ > >> > >>> > >>> My comment bellow is that only 1) is really needed to build VPP, > people can decide to use own build system like buildroot or yocto and > invoke > >>> cmake directly, and completely ignore 2) and 3). In such case selected > build system also needs to take care for dependencies like DPDK. > >> > >> FWIW, (3) includes "build/external/patches/" which patch the standard > distributions to add extra functionality. These patches could/will > presumably eventually be upstreamed, but it's pretty useful for getting > work done in the meantime. > > > > Not sure how is this related to this discussion, but to address your > concerns i just submitted changes to remove 2 out of 3 patches. 3rd one is > related to quickly library, and I will do my best to encourage authors to > upstream that :) > > Thanks! :) > > I was only pointing out that if one only does (1) (using pre-built > external packages instead of (3)) then one misses the patched > functionality. And yes, one could also build those packages separately and > apply the patches by hand, but that's a lot more work so (3) is pretty > useful is all. > > Thanks, > Chris. > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#14445): https://lists.fd.io/g/vpp-dev/message/14445 > Mute This Topic: https://lists.fd.io/mt/40243741/675095 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [muscarie...@ieee.org] > -=-=-=-=-=-=-=-=-=-=-=- >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14455): https://lists.fd.io/g/vpp-dev/message/14455 Mute This Topic: https://lists.fd.io/mt/40243741/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
