What's your recommendation to deal with existing autoconf based source?

[Ming Zhao]

First congratulation to the public launch. It's so excited to be able to use bazel again!

Since the bazel's model favors building everything from source code(and we like that too, so that we can easily switch build config to address saniztier, for example), I wonder whether there is any recommended way to handle existing autoconf based third party code. For example, I'm considering organizing a collection of publicly available google's opensource code(like gflags, glog, gperftoosl, grpc, etc) that are buildable with bazel, writing BUILD files for them seems a little silly but is still doable since it's mostly one-time effort. But I guess you guys might have better idea/plan to address that. So I would like to hear your feedback before moving forward. Thanks!

- Ming

[Han-Wen Nienhuys]

It depends a little on what the configure script really does.

One instance I recently cleaned up, used the configure script to
generate C++ headers, which can then either be checked in, or depended
on in a hdrs. Since the configure step is very slow, the latter is
only an option if you have sandbox and caching mechanism. We have this
inside google, but for Bazel, I would go with checking in the headers.

If the headers have to take on different values depending on the
architecture, you can use configurable attributes
(http://bazel.io/docs/build-encyclopedia.html#configurable-attributes)
or abi_deps (http://bazel.io/docs/build-encyclopedia.html#cc_library.abi_deps)
to select which one to use for a particular build.

--
Han-Wen Nienhuys
Google Munich
han...@google.com

[Ming Zhao]

Thank you Han-Wen. I agree it's simple to just run configure script
for the target architecture and save the output.

One thing unclear from the document is how to define target
architecture and how these information gets propagated.
I feel it's quite involved, it might require changes to
tools/cpp/{BUILD, CROSSTOOL}. But there is not much document/example
about it.
It could be nice to have an example about cross compiling for ARM, for example.

Another side question is about the help message, a lot of options have
help messages like "see description" but have no further explanation.

Thanks again.

[Han-Wen Nienhuys]

On Wed, Mar 25, 2015 at 5:39 PM, Ming Zhao <ming...@gmail.com> wrote:
> Thank you Han-Wen. I agree it's simple to just run configure script
> for the target architecture and save the output.
>
> One thing unclear from the document is how to define target
> architecture and how these information gets propagated.
> I feel it's quite involved, it might require changes to
> tools/cpp/{BUILD, CROSSTOOL}. But there is not much document/example
> about it.
> It could be nice to have an example about cross compiling for ARM, for example.

The target achitecture for C++ builds is defined in CROSSTOOL, yes.
You can select one of the entries defined there using the --cpu=flag.
This will have the effect on C++ rules and on genrules, where $(CC)
and $(CC_FLAGS) will reflect the target compiler.

The best description of CROSSTOOL is

https://github.com/google/bazel/blob/master/src/main/protobuf/crosstool_config.proto

but I admit that we ourselves usually ask the compiler team about
details in this file.

I did some experiments to compile AOSP with Bazel, and as a side
product I have a toolchain definition that might help, though. Let me
see if I can publish it somewhere.

> Another side question is about the help message, a lot of options have
> help messages like "see description" but have no further explanation.

Can you give some specific examples? A lot of experimental options
are undocumented by intention.

[Ming Zhao]

On Wed, Mar 25, 2015 at 10:05 AM, Han-Wen Nienhuys <han...@google.com> wrote:
> On Wed, Mar 25, 2015 at 5:39 PM, Ming Zhao <ming...@gmail.com> wrote:
>> Thank you Han-Wen. I agree it's simple to just run configure script
>> for the target architecture and save the output.
>>
>> One thing unclear from the document is how to define target
>> architecture and how these information gets propagated.
>> I feel it's quite involved, it might require changes to
>> tools/cpp/{BUILD, CROSSTOOL}. But there is not much document/example
>> about it.
>> It could be nice to have an example about cross compiling for ARM, for example.
>
> The target achitecture for C++ builds is defined in CROSSTOOL, yes.
> You can select one of the entries defined there using the --cpu=flag.
> This will have the effect on C++ rules and on genrules, where $(CC)
> and $(CC_FLAGS) will reflect the target compiler.
>
> The best description of CROSSTOOL is
>
> https://github.com/google/bazel/blob/master/src/main/protobuf/crosstool_config.proto
>
> but I admit that we ourselves usually ask the compiler team about
> details in this file.
>
> I did some experiments to compile AOSP with Bazel, and as a side
> product I have a toolchain definition that might help, though. Let me
> see if I can publish it somewhere.

Thanks for the pointer. I think it will be very helpful if you can

publish it somewhere.

>
>> Another side question is about the help message, a lot of options have
>> help messages like "see description" but have no further explanation.
>
> Can you give some specific examples? A lot of experimental options
> are undocumented by intention.

For example:
--compiler (a string; default: see description)
--glibc (a string; default: see description)
--grte_top (a label; default: see description)

I guess some of these options might be removed in the future, because
there is no grte in the public world.
But hopefully someone will come out with xrte as replacement.

[Kristina Chodorow]

Have you tried doing --long?

$ bazel help --long build

...

  --compiler (a string; default: see description)

    The C++ compiler to use for compiling the target.

--
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.
To post to this group, send email to bazel-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAN0GiO1zwWjhzLoFTbkF8WiEyEDFY65w-AKRADkjvUHSSnLBOA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Ming Zhao]

Thank you, --long produces much more useful help.

[Han-Wen Nienhuys]

On Wed, Mar 25, 2015 at 5:39 PM, Ming Zhao <ming...@gmail.com> wrote:

> Thank you Han-Wen. I agree it's simple to just run configure script
> for the target architecture and save the output.
>
> One thing unclear from the document is how to define target
> architecture and how these information gets propagated.
> I feel it's quite involved, it might require changes to
> tools/cpp/{BUILD, CROSSTOOL}. But there is not much document/example
> about it.
> It could be nice to have an example about cross compiling for ARM, for example.

I just put up an example of configuring a compiler at

https://github.com/hanwen/bazel-bits/blob/master/android-ndk/README.md.

Hope that helps.