On Tue May 19, 2020 at 11:31:07AM +0200, Landry Breuil wrote: > On Mon, May 18, 2020 at 07:07:27AM +0200, Rafael Sadowski wrote: > > This diff currently runs through a full amd64 bulk build. I send this > > diff in advance to discuss it. Here a list of imported port changes: > > > > - Update CMmke to 3.17.2 > > > > - Switch CMake to pyhton3 > > Makes 100% sense
... we tried before, without luck. It works with my cmake.port.mk solution. Some cmake+py ports do it wrong, this diff fixes the ports automatically) > > > - Remove all Modules under files. This should no longer be necessary. > > I like that idea, provided that doesnt cause subtle build config changes > that will result in runtime breakage... where do our modules come from ? > taken from upstream at some point, then tweaked for our needs ? were > those changes upstreamed and are not needed now, are the upstream > modules better now so that we dont need our local ones ? No idea, no comments, no useful commit msg (as I remember), it happened before I got involved. > > > - Remove our self hacked MODJAVA* MODLUA* MODPY* MODRUBY* modules. > > - Instead we help the original cmake modules, see cmake.port.mk. That > > saves and all these patches and is in my opinion more correct! > > From my understanding of the patch, the idea is to only set some module > vars if the corresponding MODULE is enabled, instead of setting the vars > in all cases ? Correct and this is the right way. > are we sure ordering of module inclusion doesnt matter then ? We are setting a cmake option, the order does not matter, if someone overwrites it, hopefully he knows what he is doing. If not we have to find this corner cases. > CONFIGURE_ARGS+= always scares me, what if something else down the chain > does CONFIGURE_ARGS= and drops all the other bits ? Use on your own risk. I'm gonna take a look around our tree. > > which patches this allows us to remove ? diff --git a/devel/cmake/patches/patch-Modules_CMakeDetermineJavaCompiler_cmake b/devel/cmake/patches/patch-Modules_CMakeDetermineJavaCompiler_cmake diff --git a/devel/cmake/patches/patch-Modules_FindJNI_cmake b/devel/cmake/patches/patch-Modules_FindJNI_cmake diff --git a/devel/cmake/patches/patch-Modules_FindJava_cmake b/devel/cmake/patches/patch-Modules_FindJava_cmake diff --git a/devel/cmake/patches/patch-Modules_FindLua_cmake b/devel/cmake/patches/patch-Modules_FindLua_cmake diff --git a/devel/cmake/patches/patch-Modules_FindOpenMP_cmake b/devel/cmake/patches/patch-Modules_FindOpenMP_cmake diff --git a/devel/cmake/patches/patch-Modules_FindPythonLibs_cmake b/devel/cmake/patches/patch-Modules_FindPythonLibs_cmake diff --git a/devel/cmake/patches/patch-Modules_FindRuby_cmake b/devel/cmake/patches/patch-Modules_FindRuby_cmake diff --git a/devel/cmake/patches/patch-Modules_Qt4ConfigDependentSettings_cmake b/devel/cmake/patches/patch-Modules_Qt4ConfigDependentSettings_cmake > > > - Fix cmake debug packages: > > - If DEBUG_PACKAGES set don't create install stripa rule. Idea by > > landry@ > > Long-term, i think upstream should be consulted about that. Upstreaming > that would be nice, instead of a local patch/hack. That said, > patch-Source_cmInstallTargetGenerator_cxx needs a comment :) We'll have to do more cleaning for that. The other BSDs have almost no patches. There is of course a comment in patch-Source_cmInstallTargetGenerator_cxx. > > > What do you think? I would like to commit this diff if the bulk build > > is successful. > > > > Opinions? > > I'm scared. Now is the right time, but i expect many weird/random > build/runtime failures later on, which might not show up in 'just > running a bulk' ... > I do not expect too much impact. ;)
