Replies: 5 comments 7 replies
-
|
No worries for me. Will this result in a change to all the cmake files? Will the synthaxe be easier to read? Out of curiosity, have you discussed switching to the Bazel build tool (https://bazel.build/), which is supposedly used extensively at SpaceX and is much more readable/simple? |
Beta Was this translation helpful? Give feedback.
-
|
Ok my bad..,thanks to @astroesteban message, I realized it was an update. |
Beta Was this translation helpful? Give feedback.
-
|
I removed the part of my message that is no longer relevant and confusing. |
Beta Was this translation helpful? Give feedback.
-
|
The only downside to requiring a more recent CMake version is that other projects that depend on F' will be forced to upgrade their CMake version. This can be resolved with a CMake update unless an update is not possible. I can't think of any immediate cases where a CMake update is not possible. I vote in favor of the update. |
Beta Was this translation helpful? Give feedback.
-
|
This is indeed an upgrade. The syntax does become quite cleaner and more expressive. It also comes with many bug fixes that allow us to further reduce workarounds in our system. |
Beta Was this translation helpful? Give feedback.
-
|
I want to push back on this a little bit. I don't think it makes any sense to arbitrarily move the required version forward, but if I am reading @LeStarch 's reply correctly then this would come with updates to the build system that leverage features in the newer cmake versions. Having a scenario where advanced users can roll back the stated cmake version and have it work is confusing. I personally do not like the "install an updated version of cmake" justification, because it tends to make it harder for new developers to get started, and annoying for advanced developers to help newbies get started. Obviously if somebody needs to develop on an ancient system, then they are on their own to set up the development environment. It is critical that F Prime not be difficult to get started, so long as the goal is to grow the community and get traction with a user base. As such, I think it makes sense to consider what reasonable development environments might look like. I DO NOT like referencing "security" via a hand-wave as a justification to upgrade a dependency, and cmake is definitely a dependency because there are no pre-compiled F Prime programs that are available for end-user use. If security is the concern, there should be specific justifications, e.g. pointers to particular CVE or known problems in a changelog, that is used as a justification for security concern. Actively maintained linux platforms will have software that has been patched for the latest security concerns anyway. In the case that a developer is working in an air-gapped environment, pulling in extra dependencies that are not provided by the pre-packaged repositories has a tendency to add an annoying burden to the developer. This brings me to point where I will suggest a path forward. I think it is prudent to support common, actively maintained versions of Linux. My particular interest is Ubuntu, where there are currently 2 LTS releases. Bionic Beaver LTS is supported until April of 2023, and Xenial has been recently dropped. Therefore, the version 3.10 as found in Bionic seems like a logical version to support. I believe that a good future:tm: would include packaged versions of F Prime as a library that are installable via the operating system's package manager. This isn't something that the F Prime team should be expected to do themselves, but if the team is cognizant of the difficulties that a package maintainer might encounter (e.g. the requirement to depend only on other packaged versions of software available to the system) then the difficulties of such a package maintainer would be much reduced. If the F Prime team does decide that my logic is valuable, it might be worth codifying the approach in a developer notes file that is consulted when decisions of this nature are being made at the next version release. Please, spar with me, let us make the future of F Prime better together! |
Beta Was this translation helpful? Give feedback.
-
|
Lots of great points @SterlingPeet! The update is targeted towards F' release v3.0.0 which in itself is already a breaking change from 2.0.0. So that's an opportune time to update the build system. I think a bump to CMake version 3.10 is a good baseline and compromise as long as the CMake features F' 3.0 wants are supported in CMake 3.10. I agree with you that we should make acquiring F Prime's dependencies as easy as Additionally, the F' project should support older versions of CMake and let projects that depend on F' decide if they want to go to a more recent version. Everything downstream of F' will be forced to upgrade if their projects using F' target an older CMake version. This can be a headache for users looking to make the leap from F' v2.0 to F' v3.0 in the future and an unnecessary burden if avoidable. I've dealt with situations where my project used CMake version 3.15 and the project it depended on use CMake version 3.10. Then I introduce a new dependency that requires 3.18 and I'm forced to upgrade CMake everywhere I build my project (host, VM, Docker, etc.). The CMake organization is really good at maintaining backwards compatibility but it's still a pain to go through an manually update packages. |
Beta Was this translation helpful? Give feedback.
-
|
@SterlingPeet thanks for your feedback. I would like to clarify some points here:
|
Beta Was this translation helpful? Give feedback.
-
|
This bring us to the to the question of what environments to support. I am going to focus on Linux. Each supported environment comes with maintenance to ensure that support for this environment is maintained. My goal is to balance usability with maintenance because as maintenance grows, bugs get through, and usability is affected. Each new supported environment means:
Our CI works but it is not a perfect solution. Using Linux as an example, we chose one distribution as the supported distribution with the knowledge that it shouldn't be too hard to adapt that to work on other distributions. We then specifically test against that distribution but not others. With releases I'd naturally choose the same approach. We select a release and point to that. If you choose to run on a different release it shouldn't be too hard but we aren't specifically testing or developing for that. We direct users who want it to "work out-of-the-box" to the selected LTS, and the install works cleanly (apt install ...). Otherwise the generic instructions to seup fprime apply. Per your comment above, I conclude that you came to a different conclusion that out-of-the-box support should work on any live LTS of Ubuntu. I am curious to know what you see that I am missing. Do a lot of your users start off with 18.04 instead of 20.04? Are your teams hesitant to adapt a cutting edge OS? |
Beta Was this translation helpful? Give feedback.
-
|
Ah, ok there is some meat to dig into here! I am interested to know what requires going to 3.13, but that is more of curiosity and does not need to be addressed here. I agree that selecting a tool release version that appears to be randomly misaligned with the target supported development environment is not ideal. 10 years ago I worked on the build and CI for MLPACK, and we used a Jenkins server to run the test suite against every combination of released dependency versions from current to the oldest we wanted to support, on each OS platform we wanted to support. It is definitely a job and it definitely takes time to run several hundred configurations through an exhaustive test suite. Fortunately, it can be mostly automated and you can have policies that favor certain combinations and allow others to fail until a cleanup step occurs [either dropping support or correcting issues] usually near a release cycle. However, how you run your CI is not the point, nor my business to dictate. Let's talk about how we end up wishing for older platforms to be supported. My experience is that brand new developers have no concern with platform age, and typically set up the newest thing they reasonably can. However, this situation can be encumbered by institutional issues. Back when I was first getting started with F Prime, I needed it to work on Xenial (16.04) because the GT IT team had not approved Bionic (18.04) for use yet, and did not do so until almost 2 years after it was released. This directly led to the creation of my F Prime Vagrant Config Project, because it was not a clean install and setup process for Xenial. Fortunately the IT team here was much quicker to adopt Focal (20.04) and was supporting those installations in May, so its not even a guarantee that this problem happens. Aside from my personal experience with institutional difficulty, I am currently transitioning two teams from F Prime 1.3+ development to F Prime 2.0 development. In both cases, developers wanted to start by test compiling on the typically Xenial development systems that they already had set up. So now I have a bunch of developers that are fighting battles on at least 3 fronts, new dev platform, new F Prime version, and compatibility issues with a non-Linux target platform. So yes, we are seeing a lot of friction here, some of which has manifested in recent discussions and probably some issues too. Alas, progress comes with strife, and as you mention: it is a balancing act that must be managed with non-trivial consideration to the maintaining developer's time. From a practical standpoint, if you have a specific issue that requires upgrading to cmake 3.13, and there is syntactical advantage that you want to use in 3.16, then combining that with the fact that 3.16 is the current Ubuntu LTS version makes it a logical choice in my mind. For me, it probably means updating the aformentioned Bionic Vagrantfile to include scripted installation of a newer cmake package. Ultimately, I wanted to see that there was more behind the choice to update than just "its the installed version on the current development platform of choice". Since that seems to be the case, and the logic follows to update the tool version, then I do think 3.16 is a good place to put down the line. |
Beta Was this translation helpful? Give feedback.
-
|
This is good for my understanding. Thanks for the detailed feedback. I do see a need to ensure that some supported version on F´2.x is also supported on F´3.x such that there is some path that does not require upgrading everything. That is: F´2.0: 18.04 and 20.04 It doesn't fix all problems, but does allow each piece to be upgraded in order. For your curiosity see the accepted answer here: https://stackoverflow.com/questions/34443128/cmake-install-targets-in-subdirectories. We are reverting to using CMake's install function for building the packages. This is part of an effort to reduce the amount of CMake code we have, and use more of what CMake provides. This also takes 50 some We are using Github actions to do our CI, so if you are curious on that, checkout the actions tab. There is still work to go there, as Github provides newer versions of tools.....but it is a start. |
Beta Was this translation helpful? Give feedback.
-
|
All, thanks for the feedback. I have decided to do the minimal bump to 3.13 for now. I think this will make it clearer, we are bumping to this version because of XYZ. In this case, see the above link to a discussion of the bug fix we need. |
Beta Was this translation helpful? Give feedback.
-
F´ users, as some of you may know, we are diligently working towards a v3.0.0 release with new tooling! As part of this effort we'd like to bump the minimum CMake version from 3.5 to 3.16.
3.16+ is consistent with the Ubuntu 20.04+ package for the CMake install. This puts us inline with the latest Ubuntu LTS release. Other systems can still download the CMake from the CMake website and install via their packages.
Are there any use cases in the community that cannot be accommodated by a CMake install or LTS package install of cmake 3.16+? Please keep in mind, at some point we will be forced to upgrade for security and stability reasons.
Many thanks!
Beta Was this translation helpful? Give feedback.
All reactions