Enhance the build experience of envoy.

[fengli79]

Today build envoy from github is not trivial. And it's even harder to build its tests.
Shall we?

1. Add envoy dependencies as its submodules?
2. Bazel support?
3. Single command to build?

[lizan]

If you can use docker to build, it is not hard and just one command to build and test:
https://lyft.github.io/envoy/docs/install/building.html

We have bazel BUILD files in https://github.com/istio/proxy , @mattklein123 are you open to merge it into envoy repo?

[rshriram]

Bazel support does not enhance build experience in any manner (not from our experience so far!). As @lizan pointed out, there is already a simple one line docker build command, and the docker image comes with all the dependencies installed in it.

[lizan]

We have been using bazel in istio/proxy for a while, and I do think bazel enhanced the build experience, especially for attaching debuggers, working with tools doesn't work well with docker. It provides dependency resolution without changing the system environment.

[Reflejo]

IMHO what needs to be done here is to fix the CMakeLists.txt to take care of dependencies. That way compiling from the repo would be as easy as setting your CXX/CC and

$ cmake .. && make

or even

$ cmake -GNinja .. && ninja

I have a working branch that I'm planning to push when I have some time to polish

[fengli79]

@Reflejo , agreed, the deps is the most painful part.
Can we add those deps as submodules of envoy if they are available on github?

[mattklein123]

Per offsite meeting, here is I think where we landed here:

• We don't mind multiple build systems, but we need a single source of truth.
• It's possible we can look at gRPC build system to see how they do both bazel and cmake.
• We are open to switching to Bazel IFF it doesn't make any of the existing flows worse and does not make CI any longer than it already is (given how slow Travis is and the fact that right now we don't have any other options).

@htuch I believe is going to take the lead on a proposal/investigation here. Going to assign to him.

[rshriram]

As long as one can build the system in a docker container, bazel or not doesn't matter. Building in a container makes things easier to develop on different platforms (use your favorite ide on the host, mount volume in the container and build). @htuch if you do go down the bazel in a container path, you would have to give folks a fair warning that all of the bazel caching stuff will be negated. And oh, if you could also provide the bazel/clion scripts that folks at Google use, it would be great. :)

On Sat, Feb 25, 2017 at 1:24 PM Matt Klein ***@***.***> wrote: Per offsite meeting, here is I think where we landed here: - We don't mind multiple build systems, but we need a single source of truth. - It's possible we can look at gRPC build system to see how they do both bazel and cmake. - We are open to switching to Bazel IFF it doesn't make any of the existing flows worse and does not make CI any longer than it already is (given how slow Travis is and the fact that right now we don't have any other options). @htuch <https://github.com/htuch> I believe is going to take the lead on a proposal/investigation here. Going to assign to him. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#415 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qd1anD26m7v7ERTAedETSCjZ9lAiDks5rgHHHgaJpZM4L1zJY> .

-- ~shriram

[fengli79]

build in docker can make it easier for multiple platforms release, but not for IDE. For example, if I'm using eclipse cdt, I would prefer to get a make file which can be imported directly. Today people has to manually configure their environment and install different kinds of dependencies, which is the pain point. GitHub submodules are preferred. On Sun, Feb 26, 2017 at 10:01 AM Shriram Rajagopalan < notifications@github.com> wrote:

…

As long as one can build the system in a docker container, bazel or not doesn't matter. Building in a container makes things easier to develop on different platforms (use your favorite ide on the host, mount volume in the container and build). @htuch if you do go down the bazel in a container path, you would have to give folks a fair warning that all of the bazel caching stuff will be negated. And oh, if you could also provide the bazel/clion scripts that folks at Google use, it would be great. :) On Sat, Feb 25, 2017 at 1:24 PM Matt Klein ***@***.***> wrote: > Per offsite meeting, here is I think where we landed here: > > - We don't mind multiple build systems, but we need a single source of > truth. > - It's possible we can look at gRPC build system to see how they do > both bazel and cmake. > - We are open to switching to Bazel IFF it doesn't make any of the > existing flows worse and does not make CI any longer than it already is > (given how slow Travis is and the fact that right now we don't have any > other options). > > @htuch <https://github.com/htuch> I believe is going to take the lead on > a proposal/investigation here. Going to assign to him. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#415 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AH0qd1anD26m7v7ERTAedETSCjZ9lAiDks5rgHHHgaJpZM4L1zJY > > . > -- ~shriram — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#415 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AT1vm5DILo90Aacx5cyAyZxLnSwnuPGcks5rgb4KgaJpZM4L1zJY> .

[htuch]

I'll start looking into this during the week. I agree that submodules could be an idea to consider, but I don't think we want to be in the business of building every single transitive dependency, even if this works today, this will put future constraints on what dependencies we can add feasibly. Envoy might have a wider set of dependencies than the gRPC core libraries which use this approach.

Whatever the outcome, the Docker build will be maintained - this is necessary for CI and some developers (including me) use this as their primary workflow. It's also orthogonal to the choice of the use of (i) submodules (ii) build system (iii) IDE, we should always be able to encapsulate the build flow in a Docker image.

[htuch]

jamessynge@ mentions that it would also be useful to not build all tests as the only option.

[htuch]

Latest discussion on this and a proposal is being tracked at https://docs.google.com/a/google.com/document/d/1XG1F38tZXTaWlrDXZFNoH-0xVm0d4HlrZJ4JXbMWqHo/edit?usp=sharing

[daedric]

Also my +1 for a better dependencies management. Using find_package() should be the first step and submodules even better so you can still have a full static build.

It would ease up a lot setup'ing dev environment.

[htuch]

I started to look at adding bazel to the Docker image as the first step in Bazelifying Envoy.

Following the instructions at https://bazel.build/versions/master/docs/install.html#ubuntu led me to installing Oracle JDK 8, as Ubuntu Trusty doesn't have OpenJDK 8 support as a starter. This comes with a big scary license http://www.oracle.com/technetwork/java/javase/terms/license/index.html, IANAL and unclear if this will fly for Docker redistribution by Lyft.

It'll probably be more sane to move to a newer Ubuntu version rather than explore unofficial OpenJDK ports, does this sound sane @mattklein123?

[lizan]

@htuch Are you trying on Ubuntu 15.10 or 14.04? AFAIK 16.04 with OpenJDK has no problem with bazel.

[htuch]

This is 14.04, the version of Ubuntu used for the Docker image. If folks are on-board, I will upgrade it to something more recent like 15.10 or 16.04 where there is OpenJDK 8 support.

[mattklein123]

16.04 should be fine. If possible can we still build with GCC 4.9? I think this is available on 16.04 pretty easily, though from my own machine, there might be some build issues (I have no idea why this would be the case but I recall potentially having an issue when trying), but let's give it a shot.

[htuch]

We should add support to generate a textual representation of the build dependency graph once done. This will provide a sanity check that we could in future support other build systems and also provide support to those who want to carry out proprietary integrations. @mattwoodyard.