-
Notifications
You must be signed in to change notification settings - Fork 668
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
Add march=native build to cron job #3442
Comments
The lazy person in me is just going to do a sed call, that's the least painful way. |
ENV variables? Not sure if they’re officially supported but sniffing for
C_FLAGS would seem sane.
…On Thu, Oct 21, 2021 at 10:55, Hugo MacDermott-Opeskin < ***@***.***> wrote:
@IAlibay <https://github.com/IAlibay> @orbeckst
<https://github.com/orbeckst> is there a canonical way to pass
installation options on the command line ? I think having this as a flag
rather than a "comment this back in" is probably cleaner.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3442 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACGSGB2TOSSA2NW4DFM76FTUH7IQ3ANCNFSM5GMWJEZA>
.
|
env variables are a bit meh IMHO. I'm pretty sure you can pass it via the setuptools CLI by subclassing something, I'll have to have a poke through some docs later. |
I guess our current setup is built for env variables, so it's probably best to stick with that, it's in the setup docs so I assume they should be officially supported. |
To expand on this - right now (on current develop) if you were to assign the env variable "MDA_MARCH=True" then it would trigger the march variable. |
I am going to close this for now, as we decided in #3429 to allow an option for any compiler flags rather than just |
I'm not sure I agree we should close - we're still going to document the use of march=native as a flag right? So we should test it... |
I guess my understanding of discussion in #3429 was that we were going to rely on the user to specify any additional compiler flags (it would be blank by default). But I see now that if we document the use of a flag specifically, we should test for it (if that is an okay use of CI resources?). Sorry for the perhaps premature close. |
It's a reminder for a weekly Cron job we'll probably add in the near future, it's not a waste of CI if it's the one job once a week IMHO. |
Do we still feel this is warranted? We give an example using custom compiler flags to do an advanced |
Let's just leave this open for now. I'm planning to restart looking into adding that cron job during the winter break, if we get it in then great, if not then it doesn't matter. |
Fixes #1727 Towards #3052 #3442 ## Work done in this PR - Implement composite actions for similar steps across multiple workflow jobs - Adds a fully tune-able composite workflow for conda/pip installing - A variety of cron jobs (running at 3 am UTC on Sunday) - pip only install - install with numpy & scipy nightly dev versions - "march=native mtune=native" cflags build
Unless there's any objections I think I'm going to go ahead and close this. As much as I would like to test that the correct optimisation options work on on arm / ppc64le, we're already doing these normally on a weekly cron with leftover Travis credits. We already warn folks to make sure they test before they run their jobs, and the weekly gh action cron job tests on x86_64. I'd say that's probably good enough. |
Agreed :) |
Is your feature request related to a problem?
Enabling of an advanced "march=native" build
setup.cfg
Issue #3428 PR #3429 means that it should be tested, including on ARM and PowerPC in the weekly cron job.Describe the solution you'd like
Add build(s) with
march=native
to the weekly cron job. We may need to have a git patch apply a change to setup.cfg OR have some way of enabling the march=native build independent of setup.cfg, eg a command line flag to setup.py.The text was updated successfully, but these errors were encountered: