improvements for pros4

[nathan-moore]

There's been some discussion around changes we'd like for pros4. In particular,

• LVGL sidelining PROS 4: Decouple LVGL and Make LVGL Template #168
• code reorganization PROS 4: Better Namespace Layout #223
• remove direct dependence on libv5rts.a (possibly)

are the major ones that we were discussing. Some of these changes breaking, so that's why we're thinking of a major version increment. It also coincides nicely with some other changes.

There was discussion elsewhere about what other changes people like to see, so part of the reason why this exists is to help document that.

[HotelCalifornia]

possibly the migration to a more modern build system, like CMake

[TixoRebel]

Also potentially add a HAL that thinly wraps the SDK to decouple the kernel from the SDK.

[theol0403]

Switch the compiler to llvm/clang, which has better tooling and more optimizations than gcc, along with the move to cmake.

Automated documentation, ie doxygen, whether it be a full migration to a new doxygen-based setup or take the autogenerated documentation and feed into read the docs (I don't think this is a great idea but I'm also still having trouble making a perfect doxygen prototype).

Motor set PID command (and related helpers) being conditionally hidden using a macro, so that:

• it does not clutter up documentation (though doxygen commands could also be used to hide method from documentation)
• since it is a dangerous command, it is not trivially accessible or found by a new user yet available when needed.

[Octogonapus]

Switch the compiler to llvm/clang

I don't think clang has support for linking against arm yet, does it? Is it still "experimental" or something?

better tooling

Does this really matter for us? We would just invoke clang .... instead of gcc ..... We aren't creating our own language here.

more optimizations than gcc

Traditionally, gcc has been the better optimizing compiler between the two of them. They have pretty much caught up, though.

[nickmertin]

I don't think clang has support for linking against arm yet, does it? Is it still "experimental" or something?

ARM support is listed on the LLD webpage.

Traditionally, gcc has been the better optimizing compiler between the two of them. They have pretty much caught up, though.

Counterpoint: using Clang and LLD would enable us to support Link-Time Optimization, which can greatly improve cross-unit optimizations, both for performance and code size. This could be especially useful for reducing monolithic executable size. There is (to my understanding) no equivalent system on the GNU stack.

[Octogonapus]

ARM support is listed on the LLD webpage.

Maybe they have added support for our Arm architecture recently. Remember that not long ago, Vex used clang for compiling and gcc for linking.

There is (to my understanding) no equivalent system on the GNU stack.

GCC has LTO.

[nickmertin]

GCC has LTO.

My bad, I was not aware of that. Looks to be pretty similar. So it probably just comes down to feature set then (including C++20 support if that's what we want to do).

[HotelCalifornia]

with CMake you would be able to use either GCC or clang as and when you want.

the one thing to watch out for is arm-none-eabi newlib support with clang---i'm still not sure how that works exactly

[nickmertin]

the one thing to watch out for is arm-none-eabi newlib support with clang---i'm still not sure how that works exactly

Yeah this is the most finicky part. In general it works, but you need to explicitly tell it where to look for headers and libraries; that info is built-in for GCC because it's all packaged together.

[WillXuCodes]

I know they're in seperate namespaces, but I still feel like we should keep the 393 motors as ADI motors and the V5 motors as normal motors. What are your guy's opinions on this? (Gonna change the 393s to motor for now).

[theol0403]

Traditionally, gcc has been the better optimizing compiler between the two of them. They have pretty much caught up, though.

In my (narrow) experience, I've noticed that clang can do more optimizations, and I've also read that the STL implementation and internals are much smaller and lighter. Also, for example, clang was able to expand a constexpr'd function containing a loop and calculate the return (container) during compile time, whereas gcc could not.

[nathan-moore]

Switch the compiler to llvm/clang, which has better tooling and more optimizations than gcc, along with the move to cmake.

This has a fairly high cost to do as we wouldn't want to support multiple different tool chains (and I don't think? you can call into different each other due to name mangling, among other things). This means installing clang on all users of pros, which is pretty high cost. From last I heard from people way more familiar with this then I am, they were about equal, with each optimizing some areas better/worse then the other. It's not something I think we should change, as it's a fair amount of work for potentially little benefit.

If we're talking about CMake for new projects, my only worry about that is that idiomatic cmake is that you add files you're compiling to a list, as it might not be able to detect some changes if you glob it. Thought given our target audience, this workflow break might be fine. I've heard people say they've never had issues with it before though, so that might also be a good approach.

[Octogonapus]

This means installing clang on all users of pros, which is pretty high cost

I would also like to add to this that users already have the gcc toolchain installed, which has proven to be a difficult task for many.

[nickmertin]

I would also like to add to this that users already have the gcc toolchain installed, which has proven to be a difficult task for many.

I second this. One nice thing about LLVM/Clang is that there's no "cross-compiler"; one set of toolchain binaries support all target. This means that users (especially on Linux) are more likely to already have things they need installed.

I don't think this should be a high priority per se, but it's something to consider.

If we're talking about CMake for new projects, my only worry about that is that idiomatic cmake is that you add files you're compiling to a list, as it might not be able to detect some changes if you glob it.

That sounds like we'd be re-introducing issues like #167, which I think we'd really like to avoid. There are so many build systems that do these things properly nowadays that there's no excuse to have that kind of bug. IMO this should be a key requirement.

Thought given our target audience, this workflow break might be fine.

Not sure what is meant by this?

[HotelCalifornia]

Here's the deal: changing the compiler we ship (with windows installs) is out of scope of this issue. The reasonable compromise is that we can provide toolchain files for GCC and for clang and let users supply their own compiler if they care to.

[theol0403]

Sounds good about the toolchain topic, I'm not qualified to argue for either side.
However, I don't like the idea of needing to manually add each source file to an index, it is a very nice feature in PROS to be able to create a new source file and it gets automatically compiled. I think globbing is worth the drawbacks.

[HotelCalifornia]

However, I don't like the idea of needing to manually add each source file to an index, it is a very nice feature in PROS to be able to create a new source file and it gets automatically compiled. I think globbing is worth the drawbacks.

This is easily fixed using cmake functions, and I'm about 75% sure this can be made to work with dependency detection as well

[Sleuth56]

I'm definitely not qualified to give my opinion as a developer. However as an advanced user I think that offering the option is fine but there are already enough flame wars about things like this for no reason and adding an other thing after you all said it doesn't really matter doesn't make sense. There are much better things to work on than changing a fundamental thing like that.

[WillXuCodes]

PROS 4 Roadmap (Work starting this summer)

Working on a proper presentation instead of a MS Paint comic sans road map soon

[WillXuCodes]

Closed due to plans being relatively more finalized and a redundant discussion board.