Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate unified build in favor of unity build. #3491

Merged
merged 9 commits into from
Feb 23, 2023

Conversation

fruffy
Copy link
Collaborator

@fruffy fruffy commented Aug 18, 2022

The custom unified build code might actually not be needed anymore. CMAKE has added UNITY_BUILDS, which seem equivalent.

I left the library in the cmake folder, in case downstream repositories still needed. There is only one build testing that the non-unity build compiles, which reduces the amount of CI runs. I can also make unity builds the default if requested.

@fruffy fruffy force-pushed the remove_unified_build branch 2 times, most recently from f22d878 to b5832b7 Compare August 18, 2022 12:19
@fruffy
Copy link
Collaborator Author

fruffy commented Aug 18, 2022

This requires fixes on some downstream repositories but otherwise works well. We may even drop the CI option to simplify tests.

@fruffy fruffy marked this pull request as ready for review August 18, 2022 12:24
@fruffy fruffy requested a review from mihaibudiu August 18, 2022 21:22
@mihaibudiu
Copy link
Contributor

Does this work with any version of cmake?
Is it faster or comparable to the old unified build?

@fruffy
Copy link
Collaborator Author

fruffy commented Aug 19, 2022

It works with CMake 3.16+, wich is the default since Ubuntu 20.04. The build times are roughly the same, but can be tweaked with UNITY_BUILD_BATCH_SIZE.

@mihaibudiu
Copy link
Contributor

I personally don't have a problem with this, but I think this should work on as many platforms as possible.
If this precludes people running older versions of the software from building, then it could be problematic.

@fruffy
Copy link
Collaborator Author

fruffy commented Aug 20, 2022

I guess it boils down how we want to maintain backwards compatibility. We dropped support for anything lower than Ubuntu 20.04 with this pull request. So it might make sense to use features that are provided by it.

The original unified_build library is still there. I can try to create a version that uses it depending on the CMake version. I was also hoping to simplify the CI with this PR. We do not need to test all combinations of unified and gmp builds.

@jfingerh
Copy link

"We dropped support for anything lower than Ubuntu 20.04 with p4lang/third-party#25 pull request."

Techically, we stopped doing automated CI testing for anything lower than Ubuntu 20.04 with that change.

There was a commit in the last month or two that broke the build for Ubuntu 18.04, which when pointed out later via an issue then caused someone to create another PR that restored a working build for Ubuntu 18.04.

@jfingerh
Copy link

I agree that at some point it definitely makes sense not to support Ubuntu 18.04. A reasonable question is: when? One choice is right now. Another would be to wait until 5 years after Ubuntu 18.04 was released in April 2023, when Ubuntu discontinues free support for it.

@fruffy
Copy link
Collaborator Author

fruffy commented Aug 21, 2022

The problem is that without CI we can not make any guarantees for 18.04. It will be quite hard to respect 18.04 restrictions going forward. This is related to the discussion in #3451. Iirc that change worked because there was a solution that works for both 18.04 and future systems. This might not always be possible.

For this particular PR, I can try to come up with a solution that can also work with older CMake systems.

@davidbolvansky
Copy link
Contributor

It works with CMake 3.16+, wich is the default since Ubuntu 20.04. The build times are roughly the same, but can be tweaked with UNITY_BUILD_BATCH_SIZE.

What is the plan now? Land this PR after April 2023? Or just land it now and one (on U18) can install newer cmake easily for example with pip install cmake==3.16.3.

@fruffy
Copy link
Collaborator Author

fruffy commented Dec 11, 2022

What is the plan now? Land this PR after April 2023? Or just land it now and one (on U18) can install newer cmake easily for example with pip install cmake==3.16.3.

I will have to revive this PR but I am not quite sure what to do with build_unified yet. I will have to implement an equivalent version so that downstream projects can still use it. It might be nicer if that explicit function were not necessary.

@jfingerh
Copy link

I have no objections to merging updates that require specific later versions of cmake on Ubuntu 18.04, as long as there are clear README directions on building on Ubuntu 18.04 somewhere.

@davidbolvansky
Copy link
Contributor

build_unified

I would remove it.

Could you create new cmake option so we could try new cmake native unified build downstream and do necessary changes?

@fruffy
Copy link
Collaborator Author

fruffy commented Feb 17, 2023

@mbudiu-vmw @vhavel This PR needs authorized approval because it touches some Testgen code.

@mihaibudiu
Copy link
Contributor

CI and cmake are not my speciality, so I'd rather have someone else comment.

@fruffy
Copy link
Collaborator Author

fruffy commented Feb 17, 2023

CI and cmake are not my speciality, so I'd rather have someone else comment.

The issue is that this PR can not be merged unless someone of the code owners approves. It is a little unfortunate.

@fruffy fruffy requested a review from vlstill February 21, 2023 14:17
@fruffy
Copy link
Collaborator Author

fruffy commented Feb 21, 2023

@vhavel @pkotikal This PR is stuck because of the reviewer lock we have on testgen files. If you have some time could you give this a review? This PR deprecates our homecooked unified build in favor of CMake's unity builds.

frontends/common/parser_options.cpp Show resolved Hide resolved
@@ -35,8 +35,15 @@ jobs:

- name: Build (Ubuntu 20.04)
run: |
tools/ci-build.sh
tools/ci-build.sh || echo "BUILD_SUCCESS=false" >> $GITHUB_ENV
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be non-required tests instead? Some already are optional -- it was possible to merge PRs even with failing macOS test when it was broken recently. Is there some other status than OK/failure the build can be set to. I'm afraid this will lead to situations when the failure is ignored for a long time.

Fix build.

Missing build_unified.

Clean up cmakelists.

Fix build flags.

Need to include GENERATED property.

Wrap clashing variable names in appropriate namespace.

Cpplint.

Simplify CI. Aggressive batch size.

Fix template.

cpplint.

Build fixes.

Fixup.
Copy link
Contributor

@mihaibudiu mihaibudiu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine, but I really don't know whether the new requirements will prevent people with older software from building the compiler.

@@ -235,7 +235,7 @@ inja::json::array_t STF::getClone(const std::map<cstring, const TestObject *> &c
return cloneJson;
}

static std::string getTestCase() {
std::string STF::getTestCaseTemplate() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how are these changes related to unified builds?

Copy link
Collaborator Author

@fruffy fruffy Feb 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When multiple of the test .cpp files are compiled together this function violates the one-definition rule and the compiler complains.

@fruffy
Copy link
Collaborator Author

fruffy commented Feb 21, 2023

This looks fine, but I really don't know whether the new requirements will prevent people with older software from building the compiler.

We do have a CI run for Ubuntu 18, which already requires some workarounds. Ubuntu 16.04 we dropped support a long time ago. I do not know about other systems.

@fruffy
Copy link
Collaborator Author

fruffy commented Feb 23, 2023

@mbudiu-vmw @vlstill and @davidbolvansky both approved but I can not merge this PR since it is missing an authoritative approval.

@jnfoster
Copy link
Contributor

I believe I have the power. Done.

@fruffy
Copy link
Collaborator Author

fruffy commented Feb 23, 2023

Thank you!

@fruffy fruffy merged commit ca1f347 into p4lang:main Feb 23, 2023
@fruffy fruffy deleted the remove_unified_build branch February 23, 2023 19:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants