-
Notifications
You must be signed in to change notification settings - Fork 52
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
macOS Fixes, main branch (2024.10.26.) #755
macOS Fixes, main branch (2024.10.26.) #755
Conversation
For some reason the misconfiguration only showed up with macOS's archiver. :-/
@@ -1,6 +1,6 @@ | |||
/** TRACCC library, part of the ACTS project (R&D line) | |||
* | |||
* (c) 2022 CERN for the benefit of the ACTS project | |||
* (c) 2022-2024 CERN for the benefit of the ACTS project |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW could consider following ACTS' change to only list the initial year instead of updating files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually partial to the convention we have in the ATLAS offline code, where we show the last modification date of each file. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. We had a discussion about this, and ultimately decided not to duplicate modification date (that's what blame is for) since it avoids it getting out of date, and the actual year being legally meaningless anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah strong support for the ACTS style of not updating these; avoids a lot of pain in the rear and it has zero legal meaning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You guys are making it sound like it's a black and white issue. But it's very much a shade of grey in my mind.
For instance, what about when we re-design some code. Let's say we break up a class into two separate classes, with "new" names. What would be the appropriate date on the files of the new classes? Would one use the current year? The year when the original class was written?
In the scheme that we've been using so far in the R&D projects, the new files would reflect both that their code came from an earlier time, and that that code has now moved into a new place.
Paul is correct, even we discussed about this in the past. There can be different legitimate conventions for this. But given that the convention in this repository has not been the one lobbied for now, if we want to switch to that convention, we need to do it clearly.
I.e. somebody should open a PR, and update all files accordingly. 🤔 And update the contribution guide. (I'm just kidding. I meant write a contribution guide...)
The sonar issue is just complaining about pseudo random numbers as usual. |
Only in Release mode, to not bloat the CI time too much.
6732f3f
to
6470016
Compare
|
Decided to add a CI test on macOS already as part of this PR. Tried to make it as simple as possible. @paulgessinger, what do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Triggered by the report from @CrossR and Fabrice, these are things that I needed to fix to make the project (without any GPU support of course...) build on macOS 15.0.1 with Xcode 16.0.
The biggest one being that
traccc_benchmarks_common
was set up very incorrectly so far. Yet, the archival application (ar
) on Linux did not complain about this for some reason. Apparently on Linux it's okay to create a static library with absolutely no content. But on macOS it clearly isn't. 🤔The rest are some conversion issues and a missing include.