I use CMake 4.3.3 (no custom settings).

I had CMake 4.3.2 a month ago when I submitted the CMake minimum version required change to trunk, to avoid that hard error (and was hitting the same error locally:

 Unexpected enablement value "i" for mod_authnz_ldap.

....that was also shown in the CI for branch 2.4.x

At that time, I chose not to submit the 'unset' workaround, even though it popped back up here in the CI runs again.



-jeff





On 2026-06-02 12:42 p.m., Vladimir Chlup wrote:
I agree that there seems to be a bit of a mixup, however, I don't think either of these two changes is necessarily required.

See this: https://github.com/jajik/httpd/actions/runs/26829154521/ <https://github.com/jajik/httpd/actions/runs/26829154521/>. It's 2.4.x running with VS 2022.*

Is it possible you have a CMake setting that treats warnings as errors? (like https://cmake.org/cmake/help/latest/variable/ CMAKE_ERROR_DEPRECATED.html <https://cmake.org/cmake/help/latest/ variable/CMAKE_ERROR_DEPRECATED.html>) Which version of CMake do you have? We might be missing something else...

Best,
Vlad

* The reason it works without the trunk fix is that in my fork `windows- latest` is still the old container with VS 2022 while apache/httpd was already moved to the new image with VS 2026.


On Tue, Jun 2, 2026 at 4:46 PM Jeff McKenna <[email protected] <mailto:[email protected]>> wrote:

    On 2026-06-02 10:45 a.m., Paul Lodge wrote:
     > Hi All,
     >
     > It might be in the best interest to move forward with Vlads
    suggestion
     > for now and update the CMAKE_MINIMUM_REQUIRED but I'd leave the 'i'
     > variable unset, as it's not an optimal solution it's ok as a
    quick fix
     > but could potentially cause headaches in the future.
     >
     > I think that the Windows side of things in general (CMake, tests
    etc)
     > need a little TLC, I don't mind looking into and taking on the task.
     >
     > Best
     >
     > Paul

    Joe seemed stressed about needing a workaround to get that branch 2.4.x
    running, and I provided the workaround.

    I actually agree not to commit the 'unset(i)', notice that I submitted
    the CMAKE_MINIMUM_REQUIRED change a month ago to trunk, as I figured
    that my unset(i) change was not optimal.  (however, to this day, I need
    that unset(i) to get branch 2.4.x to compile, as mentioned by Joe in
    his
    GitHub run).

    /me just trying to help

    Sorry all,

    -jeff




     >
     >
     > On 02/06/2026 09:19, Vladimir Chlup wrote:
     >> Hello,
     >>
     >> The issue is most likely caused by the change of the default GH
     >> Actions Windows image. See https://github.com/actions/runner-
    images/ <https://github.com/actions/runner-images/>
     >> issues/14017 You can try using `windows-2022` instead of the
    current
     >> `windows-latest`. It should behave as before.
     >>
     >> Alternatively, I have prepared a PR with a fix here: https://
     >> github.com/apache/httpd/pull/659 <http://github.com/apache/
    httpd/pull/659>
     >>
     >> Regards,
     >> Vladimír Chlup
     >>
     >>
     >> On Mon, Jun 1, 2026 at 6:45 PM Jeff McKenna
     >> <[email protected]
    <mailto:[email protected]>> wrote:
     >>
     >>     On 2026-06-01 12:53 p.m., Jeff McKenna wrote:
     >>     > On 2026-06-01 12:39 p.m., Joe Orton wrote:
     >>     >> On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:
     >>     >>> On 2026-06-01 9:54 a.m., Joe Orton wrote:
     >>     >>>> Windows builds have been failing in CI for a while, I think
     >>     because of
     >>     >>>> some changes in the GHA images.
     >>     >>>>
     >>     >>>> I burnt some Claude tokens trying to fix the trunk to no
     >>     avail [1], but
     >>     >>>> I have zero interest in this. It will be ... frustrating...
     >>     if people
     >>     >>>> start voting against future 2.4.x rcs because Windows
    builds
     >>     are broken
     >>     >>>> in some way which was trivial to catch in CI and fix
    ahead of
     >>     time.
     >>     >>>>
     >>     >>>> Example trunk failure: https://github.com/apache/httpd/
    actions/ <https://github.com/apache/httpd/actions/>
     >>     >>>> runs/25912053842/job/76159381743
     >>     >>>>
     >>     >>>> 2.4.x failure is "simpler" because of the cmake version
    mismatch:
     >>     >>>> https://github.com/apache/httpd/actions/
    runs/25488877019/ <https://github.com/apache/httpd/actions/
    runs/25488877019/>
     >>     >>>> job/74791446628
     >>     >>>> but working around that as suggested did not help.
     >>     >>>>
     >>     >>>> Regards, Joe
     >>     >>>>
     >>     >>>> [1] https://github.com/notroj/httpd/tree/refs/heads/
    maybe-fix- <https://github.com/notroj/httpd/tree/refs/heads/maybe-fix->
     >>     >>>> windows-ci
     >>     >>>
     >>     >>> Branch 2.4.x needs this change to be backported: https://
     >> github.com/ <http://github.com/>
     >>     >>> apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24
     >>     >>
     >>     >> Does that definitely work? I tried -
     >>     DCMAKE_POLICY_VERSION_MINIMUM=3.5
     >>     >> and it failed:
     >>     >> https://github.com/apache/httpd/actions/runs/26754488163/
    <https://github.com/apache/httpd/actions/runs/26754488163/>
     >>     job/78850661003
     >>     >
     >>     > Ah!  I didn't notice that attempt.  To answer your
    question: yes
     >>     that
     >>     > CMake change that I made works.  The run that you pointed
    to you
     >>     here
     >>     > makes it past that (thanks to that fix) and now breaks on a
     >>     different
     >>     > issue.
     >>     >
     >>     > I had made a change locally to avoid that error: Unexpected
     >>     enablement
     >>     > value "i" for mod_authnz_ldap
     >>     >
     >>     > But I wasn't proud of my workaround, and now I realize that I
     >>     should
     >>     > create a pull request for my workaround for that "i" error
    (if I
     >>     > remember, I had to "unset(i)" outside of a for loop, to
    avoid that
     >>     > error.  Will file a new pull request now (to the 2.4.x branch,
     >>     if you
     >>     > already applied the other fix that I mentioned).
     >>     >
     >>     >>
     >>     >>> PS. Suggest to use the Backport action in the httpd repo (we
     >>     use this
     >>     >>> and it
     >>     >>> works beautifully https://github.com/MapServer/
    MapServer/blob/ <https://github.com/MapServer/MapServer/blob/>
     >>     >>> main/.github/workflows/backport.yml
     >>     >>> )
     >>     >>
     >>     >> Sounds useful.... with writeable git ;)
     >>     >>
     >>     >>> Regarding trunk, there seems to be many changes in trunk
    that
     >>     break the
     >>     >>> Windows MSVC compiler, it would take me a while to go
    through
     >>     all of
     >>     >>> those
     >>     >>> changes (hmm I wonder why those changes made it through
    your CI
     >>     >>> tests / why
     >>     >>> they were merged before fixing the tests in Windows - as now
     >>     it seems
     >>     >>> like a
     >>     >>> mountain of fixes are needed)
     >>     >>
     >>     >> I don't know or care about either cmake or Windows, so I
    don't
     >>     have much
     >>     >> invested in this. The Windows CI started failing in early May
     >>     and I'm
     >>     >> pretty sure it was not the relevant commit to trunk which
    triggered
     >>     >> that, but an image change:
     >>     >>
     >>     >> https://github.com/apache/httpd/actions/workflows/
    windows.yml <https://github.com/apache/httpd/actions/workflows/
    windows.yml>?
     >>     >> query=branch%3Atrunk
     >>     >>
     >>     >> Regards, Joe
     >>     >>
     >>
     >>     New pull request (into branch 2.4.x) :
     >> https://github.com/apache/httpd/pull/657 <https://github.com/
    apache/httpd/pull/657>
     >>
     >>     (backports earlier change, and also tackles the error :
     >>          Unexpected enablement value "i" for mod_authnz_ldap
     >>
     >>
     >>     thanks,
     >>
     >>     -jeff
     >>
     >>
     >>
     >>     --
     >>     Jeff McKenna
     >>     GatewayGeo: Developers of MS4W, & offering MapServer
    Consulting/Dev
     >>     co-founder of FOSS4G
     >> http://gatewaygeo.com/ <http://gatewaygeo.com/>
     >>


-- Jeff McKenna
    GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
    co-founder of FOSS4G
    http://gatewaygeo.com/ <http://gatewaygeo.com/>



--
Jeff McKenna
GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
co-founder of FOSS4G
http://gatewaygeo.com/

Reply via email to