Processors and Environments about platforms HOT 9 OPEN

Just for reference here is an example of a build file that I have been working on. I understand that there is some interest in centralising these constraints into one repository. What is the intention when it comes to dealing with each subtle difference in architectures. Is there perhaps somewhere this discussion is more active?

constraint_value(
    name = "armv6-m",
    constraint_setting = "@platforms//cpu:cpu",
)

constraint_value(
    name = "armv7-m",
    constraint_setting = "@platforms//cpu:cpu",
)

constraint_value(
    name = "armv7-m-fpu",
    constraint_setting = "@platforms//cpu:cpu",
)

constraint_value(
    name = "armv7e-m",
    constraint_setting = "@platforms//cpu:cpu",
)

constraint_value(
    name = "armv7e-m-fpu",
    constraint_setting = "@platforms//cpu:cpu",
)

from platforms.

I would also like to explore this further. I am interested in cortex-m targets. There are a number of optional extensions to the instruction set on cortex-m devices. See here. In particular, DSP and FPU instruction sets. Would the desired method be to add different sub-directories containing constraint values for 'fpu', 'dsp' or 'arbitrary_instruction_set_extension'.

from platforms.

As the official document says here : https://docs.bazel.build/versions/3.4.0/platforms.html#generally-useful-constraints-and-platforms .

@silvergasp The goal of this warehouse is to ensure ecological consistency. In addition, with so many non-uniform CPU types, is there a better solution?

Another example is that there are many compiler versions under Linux. Do I need to add another constraint set? How to choose the corresponding compiler version based only on the platform? eg:

constraint_setting(name = "glibc_version")

constraint_value(
    name = "glibc_2_25",
    constraint_setting = ":glibc_version",
)

constraint_value(
    name = "glibc_2_26",
    constraint_setting = ":glibc_version",
)

toolchain(
    name = "barc_linux_toolchain_glibc225",
    exec_compatible_with = [
        "@platforms//os:linux",
        "@platforms//cpu:x86_64",
        "glibc_version:glibc_2_25"
    ],
    target_compatible_with = [
        "@platforms//os:linux",
        "@platforms//cpu:x86_64",
        "glibc_version:glibc_2_25"
    ],
    toolchain = ":barc_linux",
    toolchain_type = ":toolchain_type",
)

toolchain(
    name = "barc_linux_toolchain_glibc226",
    exec_compatible_with = [
        "@platforms//os:linux",
        "@platforms//cpu:x86_64",
        "glibc_version:glibc_2_26"
    ],
    target_compatible_with = [
        "@platforms//os:linux",
        "@platforms//cpu:x86_64",
        "glibc_version:glibc_2_26"
    ],
    toolchain = ":barc_linux",
    toolchain_type = ":toolchain_type",
)

from platforms.

Hi @yicm and @silvergasp , that's basically what I've ended up with but instead of typing all that out, I made a Starlark macro that iterates over a dictionary of platforms to build those constraint settings and toolchains.

If you need, I can extract the necessary items out of my repository and put it up on GitHub?

from platforms.

@wpieterse2825 If possible, you can provide it, thank you very much!

from platforms.

Hi @yicm, I've uploaded it here, have a look.

Also, regarding the strange is_host target in the build folder that only points to Linux and not other platforms, I develop inside a container using the VS Code remote containers extension, this also goes for the usage of the LLVM/Clang tools inside the C++ toolchain scripts.

from platforms.

Hi @wpieterse2825, I have read your code. Your idea is to define the configuration structure DEVICE_CONFIGRATIONS of different CPU architectures, and then realize the automatic generation of constraint sets and tool chains. Here I have a problem. Now that the automated tool chain generation has been realized, the tool chain suite can be generated, and the way of using the platform is more complicated. Because the platform seems to only correspond to one tool chain, it is not very friendly when there are multiple tool chains for one platform. So, do you have any views on the use of the platform under what circumstances?

from platforms.

Hi @yicm, that's exactly where I've also hit a speed bump with this solution. I tried creating a macro that will generate transitions for each of the available constraint settings, where I start of the top loop with creating transitions to the architecture, then these sub-targets start a new loop depending on the bit-size, etc. but that turned out to be too unwieldy. I'm really hoping the Bazel team can give us the vision of bazel build //:all and everything works as stated in the configuration road map. I've been following the design docs posted on their proposal repo, and it seems the work is being done, it's just taking time.

As for handling this solution more easily at the moment, I'm also quite stumped, if you have any ideas on how to do this differently, please, share with me, and I'll try to implement a solution, as I'm busy with a type of OS that I want to develop for multiple platforms from the start, using QEmu emulators to test the system on each supported platform.

from platforms.

Hi @wpieterse2825 , I think Bazel itself is not very suitable for compiling C++ projects. For example, the concept of platform, its target level is the platform, and a C++ project has multiple tool chains under the same platform, and sometimes you only need to use a certain tool chain under the platform, and sometimes you need to choose the all tool chains under the platform build project at the same time. Therefore, even if Bazel's platform function can use command bazel build //:all to compile all platforms, it is not very good in some cases.

I have just used Bazel not long ago. This is my opinion. I don't know if it is correct. I hope we can discuss it together ^_^.

from platforms.