cc_library for autoconf packages?

[Abhishek Parmar]

There are many great software packages bundled as tarballs including ones from google like gflags, gperftools, protobuf etc. I use them from my homegrown build system (that I am eager to retire in favor of bazel).

I can see myself compiling them using genproto rules using somewhat hairy configure/make cmdlines.  But how do I get the libraries built from these packages to become dependencies of other libraries/binaries such that they will get linked properly.

Any ideas or pointers to other people trying to do something similar will be much appreciated.

Thanks

Abhishek

[László Csomor]

Hi,

If you've tried anything so far, could you summarize what it was and where you got stuck?

[Abhishek Parmar]

I have not tried anything yet. But I recently hacked together a blaze like build system using scons (because I was missing blaze so much after I left google :) and speaking from that experience unless bazel gives the user some control to explicitly declare a link dependency  I do not see how libraries generated using configure|make will get linkied into targets specified using cc_binary for example.

[Greg Estren]

We might have some mechanisms that can help. I have to admit, though, I'm still not completely clear exactly which limitation you're running into. Could you sketch up a more specific pseudo-example?

--
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/30103341-cf5a-4af7-96e7-3a5135fa224a%40googlegroups.com.

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

[Ming Zhao]

To address Abhishek's specific requirement, wouldn't it make more sense to have a collection of BUILD files that just build these frequently used base libraries(as well as dealing proto library and rpc)?

I have started a basic repo on github, https://github.com/mzhaom/trunk, just in case people are interested.

But on the hand, since there is public bazel available, I don't know whether Google should at least ship their open source projects with BUILD file at least, that could eliminate a lot of manual effort to craft BUILD files.

Btw, Abhiskhek you probably haven't noticed yet, but gperftools isn't an official Google's open source project anymore.

[Abhishek Parmar]

On Mon, Mar 30, 2015 at 12:03 PM, Greg Estren <gre...@google.com> wrote:

We might have some mechanisms that can help. I have to admit, though, I'm still not completely clear exactly which limitation you're running into. Could you sketch up a more specific pseudo-example?

For example, I might build a tarball as (I am probably getting the syntx/var names wrong, but you get the idea)

genrule(name = 'foo',

             srcs = ['foo.tar.gz'],

             cmd = 'cd $BINDIR/$location; tar -xvf $SRC; cd foo;./configure;make') 

and that might produce $BINDIR/$location//lib/libfoo.a

Now I want to link against it  (and use includes from $BINDIR/$location//include/) in a cc_binary:

cc_binary(name = 'bar',

                 srcs = ['bar.cc'],

                 deps = ['foo'])

I doubt this will do the right thing for either the includes or the linking for bar.

--

-Abhishek

[Abhishek Parmar]

On Mon, Mar 30, 2015 at 4:31 PM, Ming Zhao <ming...@gmail.com> wrote:

To address Abhishek's specific requirement, wouldn't it make more sense to have a collection of BUILD files that just build these frequently used base libraries(as well as dealing proto library and rpc)?

That would definitely make sense to have a cohesive open source strategy. +grpc folks  to get it on their radar.  Having BUILD files for all google open source projects would be awesome.

 

I have started a basic repo on github, https://github.com/mzhaom/trunk, just in case people are interested.

Thanks that will certainly be handy. But converting every project's makefile is probably not scalable.  Having a bridge to these makefiles would go a long way for incremental bazel adoption.

 

But on the hand, since there is public bazel available, I don't know whether Google should at least ship their open source projects with BUILD file at least, that could eliminate a lot of manual effort to craft BUILD files.

Btw, Abhiskhek you probably haven't noticed yet, but gperftools isn't an official Google's open source project anymore.

Bummer. Where does it say that? Last release was Jan 10 2015.  tcmalloc and profilers are great tools, do you know why it is not supported anymore?

 

On Monday, March 30, 2015 at 12:03:23 PM UTC-7, Greg Estren wrote:

We might have some mechanisms that can help. I have to admit, though, I'm still not completely clear exactly which limitation you're running into. Could you sketch up a more specific pseudo-example?

On Mon, Mar 30, 2015 at 2:37 PM, Abhishek Parmar <abhi...@carbon3d.com> wrote:

I have not tried anything yet. But I recently hacked together a blaze like build system using scons (because I was missing blaze so much after I left google :) and speaking from that experience unless bazel gives the user some control to explicitly declare a link dependency  I do not see how libraries generated using configure|make will get linkied into targets specified using cc_binary for example.

On Monday, March 30, 2015 at 7:16:26 AM UTC-7, László Csomor wrote:

Hi,

If you've tried anything so far, could you summarize what it was and where you got stuck?

2015. március 30., hétfő 10:45:32 UTC+2 időpontban Abhishek Parmar a következőt írta:

There are many great software packages bundled as tarballs including ones from google like gflags, gperftools, protobuf etc. I use them from my homegrown build system (that I am eager to retire in favor of bazel).

I can see myself compiling them using genproto rules using somewhat hairy configure/make cmdlines.  But how do I get the libraries built from these packages to become dependencies of other libraries/binaries such that they will get linked properly.

Any ideas or pointers to other people trying to do something similar will be much appreciated.

Thanks

Abhishek

--
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/30103341-cf5a-4af7-96e7-3a5135fa224a%40googlegroups.com.

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

--

-Abhishek

[Ming Zhao]

On Mon, Mar 30, 2015 at 5:00 PM, Abhishek Parmar <abhi...@carbon3d.com> wrote:
> On Mon, Mar 30, 2015 at 4:31 PM, Ming Zhao <ming...@gmail.com> wrote:
>>
>> To address Abhishek's specific requirement, wouldn't it make more sense to
>> have a collection of BUILD files that just build these frequently used base
>> libraries(as well as dealing proto library and rpc)?
>
>
> That would definitely make sense to have a cohesive open source strategy.
> +grpc folks to get it on their radar. Having BUILD files for all google
> open source projects would be awesome.
>
>>
>>
>> I have started a basic repo on github, https://github.com/mzhaom/trunk,
>> just in case people are interested.
>
>
> Thanks that will certainly be handy. But converting every project's makefile
> is probably not scalable. Having a bridge to these makefiles would go a
> long way for incremental bazel adoption.
>
>>
>>
>> But on the hand, since there is public bazel available, I don't know
>> whether Google should at least ship their open source projects with BUILD
>> file at least, that could eliminate a lot of manual effort to craft BUILD
>> files.
>>
>> Btw, Abhiskhek you probably haven't noticed yet, but gperftools isn't an
>> official Google's open source project anymore.
>
>
> Bummer. Where does it say that? Last release was Jan 10 2015. tcmalloc and
> profilers are great tools, do you know why it is not supported anymore?

This was discussed on the gperftools mailing list:
https://groups.google.com/d/msg/google-perftools/ilOWho3XU74/OFXiAxzWdNUJ

I agree they're great tools and I expect more stuff to come out since
bazel's opensource has cleared a few obstacles, but I was very sad to
discover it's not official anymore.