Feature request: enable automated building

[maddyscientist]

At present the MILC build system requires manual copying and editing of the Makefile to set building options, e.g., whether to build with QUDA of QPhiX support. This prevents automated testing of MILC.

While using cmake or even autotools would be the most user friendly, and most desired from our perspective, I note that simply extending the current Makefile to support environment variables for setting paths would give the rudimentary support we would like.

E.g., from the current Makefile, there is:

WANTQUDA    = true
WANT_CL_BCG_GPU = false                                                                                                                                                                                                                                                                                                                                                   
WANT_FN_CG_GPU = true
WANT_FL_GPU = true
WANT_FF_GPU = true
WANT_GF_GPU = true

If this was simply changed to

WANTQUDA    ?= true
WANT_CL_BCG_GPU ?= false                                                                                                                                                                                                                                                                                                                                                   
WANT_FN_CG_GPU ?= true
WANT_FL_GPU ?= true
WANT_FF_GPU ?= true
WANT_GF_GPU ?= true

then the user could set these variables with environment variables, overriding the contents of the Makefile. This could easily be extended to the QIO, QMP, and other options as needed.

Background: we (@mathiaswagner and I) would like to enable QUDA's pull request system to fetch the latest develop version of MILC, build QUDA-enabled MILC and run MILC's internal rhmc and rhmd tests for each pull request for QUDA. This will prevent any regressions in MILC compatibility as QUDA continues to rapidly evolve and will prevent wasted cycles going forward.

Thoughts?

[stevengottlieb]

I would have no objection the suggested change. However, I was also wondering if an alternative solution is to have one specific Makefile that is customized for QUDA and that could be the one copied to the directory in which MILC is being compiled.

…

On Fri, 2017-07-14 at 16:57 +0000, maddyscientist wrote: At present the MILC build system requires manual copying and editing of the Makefile to set building options, e.g., whether to build with QUDA of QPhiX support. This prevents automated testing of MILC. While using cmake or even autotools would be the most user friendly, and most desired from our perspective, I note that simply extending the current Makefile to support environment variables for setting paths would give the rudimentary support we would like. E.g., from the current Makefile, there is: WANTQUDA = true WANT_CL_BCG_GPU = false WANT_FN_CG_GPU = true WANT_FL_GPU = true WANT_FF_GPU = true WANT_GF_GPU = true If this was simply changed to WANTQUDA ?= true WANT_CL_BCG_GPU ?= false WANT_FN_CG_GPU ?= true WANT_FL_GPU ?= true WANT_FF_GPU ?= true WANT_GF_GPU ?= true then the user could set these variables with environment variables, overriding the contents of the Makefile. This could easily be extended to the QIO, QMP, and other options as needed. Background: we ***@***.*** and I) would like to enable QUDA's pull request system to fetch the latest develop version of MILC, build QUDA-enabled MILC and run MILC's internal rhmc and rhmd tests for each pull request for QUDA. This will prevent any regressions in MILC compatibility as QUDA continues to rapidly evolve and will prevent wasted cycles going forward. Thoughts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[detar]

Hi Kate and Steve, @kate: Your suggestion is fine. I'll add that to my list for future improvements. I know the MILC build system is clunky. @Steve: I would prefer not to have a proliferation of official custom Makefiles -- it would multiply the maintenance effort, since there would be a lot of duplication between them that would then require duplicated updates. Best, Carleton

…

On 07/14/2017 11:10 AM, stevengottlieb wrote: I would have no objection the suggested change. However, I was also wondering if an alternative solution is to have one specific Makefile that is customized for QUDA and that could be the one copied to the directory in which MILC is being compiled. On Fri, 2017-07-14 at 16:57 +0000, maddyscientist wrote: > At present the MILC build system requires manual copying and editing > of the Makefile to set building options, e.g., whether to build with > QUDA of QPhiX support. This prevents automated testing of MILC. > > While using cmake or even autotools would be the most user friendly, > and most desired from our perspective, I note that simply extending > the current Makefile to support environment variables for setting > paths would give the rudimentary support we would like. > > E.g., from the current Makefile, there is: > > WANTQUDA = true > WANT_CL_BCG_GPU = false > WANT_FN_CG_GPU = true > WANT_FL_GPU = true > WANT_FF_GPU = true > WANT_GF_GPU = true > If this was simply changed to > > WANTQUDA ?= true > WANT_CL_BCG_GPU ?= false > WANT_FN_CG_GPU ?= true > WANT_FL_GPU ?= true > WANT_FF_GPU ?= true > WANT_GF_GPU ?= true > then the user could set these variables with environment variables, > overriding the contents of the Makefile. This could easily be extended > to the QIO, QMP, and other options as needed. > > Background: we ***@***.*** and I) would like to enable QUDA's pull > request system to fetch the latest develop version of MILC, build > QUDA-enabled MILC and run MILC's internal rhmc and rhmd tests for each > pull request for QUDA. This will prevent any regressions in MILC > compatibility as QUDA continues to rapidly evolve and will prevent > wasted cycles going forward. > > Thoughts? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. > > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF_j3mD1eT5PXQvMEXMRqdMQjdMrqzl5ks5sN6EVgaJpZM4OYfUE>.

[mathiaswagner]

Thanks Carleton. That will make scripting the MILC build a lot easier.

[detar]

Done (for QUDA macros) and pushed to milc_qcd/develop.

…

On 7/14/17 10:57 AM, maddyscientist wrote: At present the MILC build system requires manual copying and editing of the Makefile to set building options, e.g., whether to build with QUDA of QPhiX support. This prevents automated testing of MILC. While using cmake or even autotools would be the most user friendly, and most desired from our perspective, I note that simply extending the current Makefile to support environment variables for setting paths would give the rudimentary support we would like. E.g., from the current Makefile, there is: WANTQUDA =true WANT_CL_BCG_GPU =false WANT_FN_CG_GPU =true WANT_FL_GPU =true WANT_FF_GPU =true WANT_GF_GPU =true If this was simply changed to WANTQUDA?=true WANT_CL_BCG_GPU?=false WANT_FN_CG_GPU?=true WANT_FL_GPU?=true WANT_FF_GPU?=true WANT_GF_GPU?=true then the user could set these variables with environment variables, overriding the contents of the Makefile. This could easily be extended to the QIO, QMP, and other options as needed. Background: we ***@***.*** <https://github.com/mathiaswagner> and I) would like to enable QUDA's pull request system to fetch the latest develop version of MILC, build QUDA-enabled MILC and run MILC's internal rhmc and rhmd tests for each pull request for QUDA. This will prevent any regressions in MILC compatibility as QUDA continues to rapidly evolve and will prevent wasted cycles going forward. Thoughts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF_j3jgWBBBuvFybezNY3W1rufYG857Dks5sN54JgaJpZM4OYfUE>.