Best practices for writing bazel rules for third party code?

[Chet Gnegy]

I've been trying to get a few third party libraries built and working with bazel, and I'm kind of stuck on what to do.

Though the specifics shouldn't matter, I'm trying to build the VST SDK (http://www.steinberg.net/en/company/developers.html)

I am trying to wrap everything in a cc_library rule. I include all the headers I need relative to the BUILD file in this rule. However, some of those headers include other headers that are specified as relative paths, not absolute paths (because obviously they have no knowledge of my WORKSPACE). My best guess at what to do is add a -I in the copts for the directory that the file (relatively included file) is in. Sometimes I get a little farther doing this, but I'm not getting this to work in all cases. How do others deal with this?

[Kristina Chodorow]

Pretty much the way you're doing.  You can use the includes=[] attribute to transitively add directories to the include paths, but it's pretty powerful so copts is safer.  Where isn't copts working?

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/1206dcc2-479e-4fb9-bf94-e4f295b2958b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chet Gnegy]

First off, sorry for the horribly late response. This never came to my inbox (not the first time I've had mail-related issues with this list, not sure why).

I looked into this again today and I was able to make it work with what I think is a gross looking copt. The third party library includes things from its root unless the header and cc are in the same directory in which case they just #include the unqualified file name. I added "-I." to include the root to copts and it built. I'm all ears for a better solution because this one doesn't seem very clean.

Small aside, there's a chance I'll have to change it to an include because of a dependency in another library (I may actually would need that include to propagate). When I do so, I get a warning because my third party directory is called ThirdParty instead of third_party. A small feature request would be the ability to designate a directory as third party without forcing adoption of google3's naming convention. 

Thanks for the reply!

On Tuesday, September 6, 2016 at 11:50:03 AM UTC-7, Kristina Chodorow wrote:

Pretty much the way you're doing.  You can use the includes=[] attribute to transitively add directories to the include paths, but it's pretty powerful so copts is safer.  Where isn't copts working?

On Mon, Sep 5, 2016 at 10:47 PM, Chet Gnegy <chet...@gmail.com> wrote:

I've been trying to get a few third party libraries built and working with bazel, and I'm kind of stuck on what to do.

Though the specifics shouldn't matter, I'm trying to build the VST SDK (http://www.steinberg.net/en/company/developers.html)

I am trying to wrap everything in a cc_library rule. I include all the headers I need relative to the BUILD file in this rule. However, some of those headers include other headers that are specified as relative paths, not absolute paths (because obviously they have no knowledge of my WORKSPACE). My best guess at what to do is add a -I in the copts for the directory that the file (relatively included file) is in. Sometimes I get a little farther doing this, but I'm not getting this to work in all cases. How do others deal with this?

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

[Chet Gnegy]

>> I looked into this again today and I was able to make it work with what I think is a gross looking copt. The third party library includes things from its root unless the header and cc are in the same directory in which case they just #include the unqualified file name. I added "-I." to include the root to copts and it built. I'm all ears for a better solution because this one doesn't seem very clean.

Sorry, I may be mistaken about my include working. I'm going to investigate further.

[Chet Gnegy]

More info in case anyone sees anything. My current build rule is below. I also showed some of the includes in comments as listed in the file.

cc_library(

    name = "VST",

    hdrs = [  # These are all referenced from the root.

        "pluginterfaces/base/funknown.h",

        "pluginterfaces/vst2.x/aeffect.h",

        "pluginterfaces/vst2.x/aeffectx.h",

        "pluginterfaces/vst2.x/vstfxstore.h",

        "public.sdk/source/vst2.x/aeffeditor.h",

        "public.sdk/source/vst2.x/audioeffect.h",   # include listed as "pluginterfaces/vst2.x/aeffect.h"

        "public.sdk/source/vst2.x/audioeffectx.h",  # includes listed as "audioeffect.h" and

                                                    # "pluginterfaces/vst2.x/aeffectx.h

    ],

    srcs = [

        "public.sdk/source/vst2.x/audioeffectx.cpp",

        "public.sdk/source/vst2.x/audioeffect.cpp", # includes listed as "audioeffect.h" and "aeffeditor.h"

    ],

    includes = [

        "-Ipluginterfaces/vst2.x",

        "-Ipublic.sdk/source/vst2.x",

    ],

)

And here's my error:

ERROR: /my_WORKSPACE_directory/ThirdParty/vst_sdk/BUILD:5:1: C++ compilation of rule '//ThirdParty/vst_sdk:VST' failed: linux-sandbox failed: error executing command /home/chetgnegy/.cache/bazel/_bazel_chetgnegy/703b9800778fef35edeb624f262556cf/execroot/Source/_bin/linux-sandbox ... (remaining 53 argument(s) skipped).

In file included from ThirdParty/vst_sdk/public.sdk/source/vst2.x/audioeffectx.h:38:0,

                 from ThirdParty/vst_sdk/public.sdk/source/vst2.x/audioeffectx.cpp:35:

ThirdParty/vst_sdk/public.sdk/source/vst2.x/audioeffect.h:38:60: fatal error: pluginterfaces/vst2.x/aeffect.h: No such file or directory

compilation terminated.

Target //ThirdParty/vst_sdk:VST failed to build

Use --verbose_failures to see the command lines of failed build steps.

INFO: Elapsed time: 0.106s, Critical Path: 0.07s

I don't really understand why it's not finding things that are referenced from the root (of the third party library, not of my WORKSPACE). I *think* it is doing ok with the unqualified relative includes. Perhaps this is resolved by doing multiple cc_libraries? I'm pretty stumped.

[Brian Silverman]

-I flags need to be from the root of the repository (so I think you want -IThirdParty/vst_sdk/pluginterfaces/vst2.x etc). The compiler is executed from a directory mirroring the root of the source tree, and Bazel doesn't do anything special with compiler flags. The includes attribute, however, has paths relative to the package (so includes = ['.'] is sometimes a good idea).

I'm surprised that adding -I. did anything. I'm pretty sure Bazel usually adds that automatically (or maybe with -isystem).

I'm not sure why some of them seem to be working. C++ toolchains paths are complicated... I don't have any particular ideas, but more general toolchain path debugging. Maybe try --copt=-v and look for anything surprising? Maybe you have some of the same headers on your system include path? Maybe you're just seeing different files fail each time you try because Bazel picks a random one to try first?

As far as the warning for using includes outside of third_party, according to #1286 it should be gone in master.

--

You received this message because you are subscribed to the Google Groups "bazel-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/3be6138c-05af-4f42-9c5e-6177f21f30a4%40googlegroups.com.