how do I move files in bazel when building a cc_library?

Question

When building projects from source in bazel, the header files do not always end at the correct relative paths.

For example, I'd like to build expat from source.
The main header that other software will use is <expat.h> .
However, the project has the source code in expat/lib/expat.h .

I can build the project successfully with:

cc_library(
    name = "expat",
    srcs = [
        "lib/xmlparse.c",
        "lib/xmlrole.c",
        "lib/xmltok.c",
    ],
    hdrs = [
        "expat_config.h",
        "lib/ascii.h",
        "lib/asciitab.h",
        "lib/expat.h",
        "lib/expat_external.h",
        "lib/iasciitab.h",
        "lib/internal.h",
        "lib/latin1tab.h",
        "lib/nametab.h",
        "lib/siphash.h",
        "lib/utf8tab.h",
        "lib/xmlrole.h",
        "lib/xmltok.h",
        "lib/xmltok_impl.c",
        "lib/xmltok_impl.h",
        "lib/xmltok_ns.c",
    ],
    includes = [
        ".",
        "lib",
    ],
    visibility = ["//visibility:public"],
)

but now other projects that try to link with @expat//:expat will be unable to find <expat.h> . The correct inclusion would need to be <expat/lib/expat.h> which is not feasible to change in other software.

What's the best way to build the project as-is, but still ensure the header files are in the correct place for other projects that use them? I'm wondering if I need to perform a cp somehow within skylark first before calling the cc_library , or if I can move the headers afterward. I don't want to change the actual contents of the project (because I may not be hosting it or I want the mirror to remain consistent). I'm not sure how I would write a rule to do this.

Answer 1

I solved this by moving each file individually via separate rules.

First, I made a rule over mv :

def mv_file(name, file_from, file_to):

    native.genrule(
        name = name,
        srcs = [file_from],
        outs = [file_to],
        output_to_bindir = 1,
        cmd = "mv $< $@",
    )

Then in the BUILD file for the dependency I used it as follows:

mv_file("xmlparse_c","expat/lib/xmlparse.c","xmlparse.c")
mv_file("xmlrole_c","expat/lib/xmlrole.c","xmlrole.c")
mv_file("xmltok_c","expat/lib/xmltok.c","xmltok.c")
mv_file("ascii_h","expat/lib/ascii.h","ascii.h")
mv_file("asciitab_h","expat/lib/asciitab.h","asciitab.h")
mv_file("expat_h","expat/lib/expat.h","expat.h")
mv_file("expat_external_h","expat/lib/expat_external.h","expat_external.h")
mv_file("iasciitab_h","expat/lib/iasciitab.h","iasciitab.h")
mv_file("internal_h","expat/lib/internal.h","internal.h")
mv_file("latin1tab_h","expat/lib/latin1tab.h","latin1tab.h")
mv_file("nametab_h","expat/lib/nametab.h","nametab.h")
mv_file("siphash_h","expat/lib/siphash.h","siphash.h")
mv_file("utf8tab_h","expat/lib/utf8tab.h","utf8tab.h")
mv_file("xmlrole_h","expat/lib/xmlrole.h","xmlrole.h")
mv_file("xmltok_h","expat/lib/xmltok.h","xmltok.h")
mv_file("xmltok_impl_c","expat/lib/xmltok_impl.c","xmltok_impl.c")
mv_file("xmltok_impl_h","expat/lib/xmltok_impl.h","xmltok_impl.h")
mv_file("xmltok_ns_c","expat/lib/xmltok_ns.c","xmltok_ns.c")

cc_library(
    name = "expat",
    srcs = [
        "xmlparse.c",
        "xmlrole.c",
        "xmltok.c",
    ],
    hdrs = [
        "expat/expat_config.h",
        "ascii.h",
        "asciitab.h",
        "expat.h",
        "expat_external.h",
        "iasciitab.h",
        "internal.h",
        "latin1tab.h",
        "nametab.h",
        "siphash.h",
        "utf8tab.h",
        "xmlrole.h",
        "xmltok.h",
        "xmltok_impl.c",
        "xmltok_impl.h",
        "xmltok_ns.c",
    ],
    includes = [
        ".",
    ],
    deps = [
    ],
    visibility = ["//visibility:public"],
)

Confusingly, I did not need to specify the moved target names in expat's cc_library . I'm not sure how bazel knows to run all of the mv_file targets first before building the expat target, but it seems to work. And I was unable to set the mv_file target names as deps to the cc_library , but maybe there is a way around that to ensure actions are properly specified in terms of their dependencies.