Skylark rules for STM32

[Pedro Kiefer]

I'm trying to create a set of rules for building embedded bare metal projects using STM32 arm's.

So far it's working great, but outputting a great deal of warnings like this one:

WARNING: trunk/BUILD:293:1: in srcs attribute of cc_library rule //:hal_smart_pic_v2: please do not import '@stm32//Drivers/STM32F4xx_HAL_Driver/Src:stm32f4xx_hal.c' directly. You should either move the file to this package or depend on an appropriate rule there. Since this rule was created by the macro 'stm32f4_binary', the error might have been caused by the macro implementation in /home/pedro/.cache/bazel/_bazel_pedro/3c6877b00a85c408a112e7fc3473f349/external/stm32/stm32f4/rules.bzl:42:16.

I cannot create a cc_library with stm32f4xx_hal.c and the other files of the warning as they depend on the processor type and some other flags that will be defined by the user of the rule (or can ?!). Right now I have a filegroup listing those files, and my macro use it, but I get this awful warnings.

The rules repo:

https://github.com/pedrokiefer/rules_stm32

Any ideas on how I should fix this is highly appreciated.

Cheers,

Pedro

[tim.b...@gmail.com]

Ha, turns out I'm actually knee-deep in doing the same. Have most of the stm32cubef4 library compiling now. As for the processor type, I've gotten around that by doing one of two things:

1) bazel build --copt=-DSTM32F446xx
2) adding "build --copt=-DSTM32F446xx" to .bazelrc in that directory

I'm doing similar techniques to compile the DSP_Lib CMSIS driver as well (e.g. -DARM_MATH_CM4, -D__FPU_PRESENT, etc).

[Irina Iancu]

+Marcel, can you take a look at 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-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/bd98dd26-987d-4b6d-a5a1-6775a823cd1d%40googlegroups.com.

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

[Marcel Hlopko]

Hi Pedro and Tim,

sorry for the slow reply, I'm still recovering from the vacation :)

You can do what Tim suggested, maybe tuning it a little by using select function. That's the first thing that I'd try when dealing with platform specific sources. For an example, you can check how bazel client gets built.

Cheers!

On Tue, Feb 21, 2017 at 10:31 AM Irina Iancu <elena...@google.com> wrote:

+Marcel, can you take a look at this?

On Mon, Feb 20, 2017 at 11:50 PM, <tim.b...@gmail.com> wrote:

Ha, turns out I'm actually knee-deep in doing the same. Have most of the stm32cubef4 library compiling now. As for the processor type, I've gotten around that by doing one of two things:

1) bazel build --copt=-DSTM32F446xx
2) adding "build --copt=-DSTM32F446xx" to .bazelrc in that directory

I'm doing similar techniques to compile the DSP_Lib CMSIS driver as well (e.g. -DARM_MATH_CM4, -D__FPU_PRESENT, etc).

On Wednesday, February 15, 2017 at 12:18:58 PM UTC-8, Pedro Kiefer wrote:
> I'm trying to create a set of rules for building embedded bare metal projects using STM32 arm's.
> So far it's working great, but outputting a great deal of warnings like this one:
>
>
>
> WARNING: trunk/BUILD:293:1: in srcs attribute of cc_library rule //:hal_smart_pic_v2: please do not import '@stm32//Drivers/STM32F4xx_HAL_Driver/Src:stm32f4xx_hal.c' directly. You should either move the file to this package or depend on an appropriate rule there. Since this rule was created by the macro 'stm32f4_binary', the error might have been caused by the macro implementation in /home/pedro/.cache/bazel/_bazel_pedro/3c6877b00a85c408a112e7fc3473f349/external/stm32/stm32f4/rules.bzl:42:16.
>
>
>
> I cannot create a cc_library with stm32f4xx_hal.c and the other files of the warning as they depend on the processor type and some other flags that will be defined by the user of the rule (or can ?!). Right now I have a filegroup listing those files, and my macro use it, but I get this awful warnings.
>
>
> The rules repo:
> https://github.com/pedrokiefer/rules_stm32
>
>
>
> Any ideas on how I should fix this is highly appreciated.
>
>
> Cheers,
> Pedro

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/bd98dd26-987d-4b6d-a5a1-6775a823cd1d%40googlegroups.com.

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

--

-- 

Marcel Hlopko | Software Engineer | hlo...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle | Registergericht und -nummer: Hamburg, HRB 86891

[Pedro Kiefer]

Marcel,

I'm not sure if using select fix the problem, I'll try though. The issue I have, and I think Tim got it as well, is that to build stm32_hal library one needs the headers files generated on the target project. At first I had all sources (hal, my project, etc) at hand, so it was easy to create a cc_library which included all of stm32_hal sources and the necessary (target generated headers (mainly HAL configuration)), this works perfectly. So imagine that now I have 20 different projects and I don't want to keep a copy of stm32_hal sources for each project, just the generated headers.

How can I define a generic stm32_hal library which depends on my project sources? I've tried on macro using native.cc_library and having stm32_hal sources as a filegroup but that gives the warning from the first email. Ideally I would like to have a skylark rule `stm32_gen_hal_library(name, processor, project_headers)`, which generates a cc_library with the correct configuration for the processor and project at hand. So on my project I would have something like:

WORKSPACE:

git_repository(

     name = "stm32",

     remote = "https://github.com/pedrokiefer/rules_stm32.git",

     commit = "f7e376c36cea54aa3317cdc02ca8fc2bf6d72fda",

)

load("@stm32//stm32f4:rules.bzl", "arm_none_repository")

arm_none_repository()

BUILD:

load("@stm32//stm32f4:rules.bzl", "stm32_gen_hal_library", "stm32_binary")

stm32_gen_hal_library(

     name = "my_hal",

     processor = "STM32F429xx",

     project_headers = [

        "Inc/mxconstants.h",

        "Inc/stm32f4xx_hal_conf.h",

        "Inc/stm32f4xx_it.h",

     ]

)

stm32_binary(

     name = "my_project",

     processor =  "STM32F429xx",

     srcs = [ ... ],

     deps = [ ":my_hal" ],

     linker_script = "STM32F429ZITx_FLASH.ld",

)

     

On Fri, Feb 24, 2017 at 11:51 AM, 'Marcel Hlopko' via bazel-discuss <bazel-...@googlegroups.com> wrote:

Hi Pedro and Tim,

sorry for the slow reply, I'm still recovering from the vacation :)

You can do what Tim suggested, maybe tuning it a little by using select function. That's the first thing that I'd try when dealing with platform specific sources. For an example, you can check how bazel client gets built.

Cheers!

On Tue, Feb 21, 2017 at 10:31 AM Irina Iancu <elena...@google.com> wrote:

+Marcel, can you take a look at this?

On Mon, Feb 20, 2017 at 11:50 PM, <tim.b...@gmail.com> wrote:

Ha, turns out I'm actually knee-deep in doing the same. Have most of the stm32cubef4 library compiling now. As for the processor type, I've gotten around that by doing one of two things:

1) bazel build --copt=-DSTM32F446xx
2) adding "build --copt=-DSTM32F446xx" to .bazelrc in that directory

I'm doing similar techniques to compile the DSP_Lib CMSIS driver as well (e.g. -DARM_MATH_CM4, -D__FPU_PRESENT, etc).

On Wednesday, February 15, 2017 at 12:18:58 PM UTC-8, Pedro Kiefer wrote:
> I'm trying to create a set of rules for building embedded bare metal projects using STM32 arm's.
> So far it's working great, but outputting a great deal of warnings like this one:
>
>
>
> WARNING: trunk/BUILD:293:1: in srcs attribute of cc_library rule //:hal_smart_pic_v2: please do not import '@stm32//Drivers/STM32F4xx_HAL_Driver/Src:stm32f4xx_hal.c' directly. You should either move the file to this package or depend on an appropriate rule there. Since this rule was created by the macro 'stm32f4_binary', the error might have been caused by the macro implementation in /home/pedro/.cache/bazel/_bazel_pedro/3c6877b00a85c408a112e7fc3473f349/external/stm32/stm32f4/rules.bzl:42:16.
>
>
>
> I cannot create a cc_library with stm32f4xx_hal.c and the other files of the warning as they depend on the processor type and some other flags that will be defined by the user of the rule (or can ?!). Right now I have a filegroup listing those files, and my macro use it, but I get this awful warnings.
>
>
> The rules repo:
> https://github.com/pedrokiefer/rules_stm32
>
>
>
> Any ideas on how I should fix this is highly appreciated.
>
>
> Cheers,
> Pedro

--
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/bd98dd26-987d-4b6d-a5a1-6775a823cd1d%40googlegroups.com.

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

--

-- 

Marcel Hlopko | Software Engineer | hlo...@google.com | 

Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle | Registergericht und -nummer: Hamburg, HRB 86891

--

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/CAFuL9GnMT0kUY2QeZMCeKDSfOyukk6gTOgBrxXVt9qy6EwXLVQ%40mail.gmail.com.

[Brian Silverman]

I think copying the files to the current package and then using the copied versions as srcs to the cc_library would work (copy them into a my_hal__sources folder or something). I think you'd need to write a custom rule to do that. Not the nicest solution, but it should work without too much hassle.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAMA%2B0V-ANDLysanApZ6tZ%2B_yzXDx__8dzs4B9osR_oC2Chvh5Q%40mail.gmail.com.

[Pedro Kiefer]

Brian,

Copying worked perfectly, not the nicest solution, but in the mean time it's working. :-) Thanks for the idea.

[tim.b...@gmail.com]

I've been toying around with custom rules to try to copy external library sources into the current package, but I'm running into a chicken-and-egg sort of problem.

1) Create a rule to copy all the files from a label (e.g. @external_lib//:all_files) into the current package's directory
2) The label from #1 is expanded during the analysis stage, and source files are available in ctx.attr.<name>.files
3) For every input file, create a new output file for it via ctx.new_file
4) Perform copy via ctx.action(inputs=<external package source files>, outputs=<all the ctx.new_files created>)
5) return struct(files=depset(<all the ctx.new_files created>))

So far, so good; the files are generated and the new rule builds successfully. However, the rule from #1 cannot fully determine its outputs until until we've passed into analysis phase. By that time it's too late for any cc_library rules to include it, as they were never explicitly declared as an output of the copy rule during loading.

I can think of two ways to approach this, both of which are apparently not possible:
1) Add to the known outputs inside the rule()'s "implementation=XX" function. Not possible, since the implementation is evaluated during analysis time, not load.
2) Expand the label to all source files during load time, e.g. in a "_GenOutputs" function passed to "rule(..., outputs=_GenOutputs)". Not possible, since the expansion isn't performed during loading phase.

Any ideas on how to get analysis-time-derived-outputs to be recognized by other rules like cc_library?

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

>
> To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/bd98dd26-987d-4b6d-a5a1-6775a823cd1d%40googlegroups.com.
>
>
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>
> --
>
>
> -- 
>
>
>
>
>
>
>
>
>
>
> Marcel Hlopko | Software Engineer | hlo...@google.com | 
>
>
>
> Google Germany GmbH | Erika-Mann-Str. 33  | 80636 München | Germany | Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle | Registergericht und -nummer: Hamburg, HRB 86891
>
>
>
>
> --
>
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAFuL9GnMT0kUY2QeZMCeKDSfOyukk6gTOgBrxXVt9qy6EwXLVQ%40mail.gmail.com.
>
>
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>
>
>
> --
>
> 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.

[Brian Silverman]

I think you want to just put the copy rule's label in the srcs of the cc_library. That will use everything from the 'files' provider as source files.

Some more explanation: Declared rule outputs are actually orthogonal to the 'files' provider, and I've found 'files' to be useful much more often. The 'files' provider is used when a dependent rules does ctx.files.<attr_name> or ctx.attr.<attr_name>.files etc (basically when it's looking for input files). The declared rule outputs determine what you can access by name outside of the rule. This means things like building the output directly on the command line or putting the name of the output files into another rule.

Here's something I was playing with which does build and I think is what you're talking about:

test.bzl:

def _impl(ctx):

  foo = ctx.new_file('foo.cc')

  ctx.action(

    inputs = ctx.files.srcs,

    outputs = [foo],

    command = 'cp %s %s' % (ctx.files.srcs[0].path, foo.path),

  )

  return struct(

    files = set([foo]),

  )

test = rule(_impl,

  attrs = {

    'srcs': attr.label_list(allow_files=True),

  },

)

BUILD:

load('//:test.bzl', 'test')

test(

  name = 't',

  srcs = [

    'src',

  ],

)

cc_library(

  name = 'c',

  srcs = [

    ':t',

  ],

)

# This doesn't work because foo.cc isn't in the outputs of :t.

#cc_library(

#  name = 'broken',

#  srcs = [

#    'foo.cc',

#  ],

#)