On Mon, 18 May 2026 at 02:10, Nathan Hartman <[email protected]> wrote:
> On Sun, May 17, 2026 at 11:18 AM Daniel Sahlberg < > [email protected]> wrote: > >> Den sön 17 maj 2026 kl 14:56 skrev Timofei Zhakov <[email protected]>: >> > >> > On Sat, May 16, 2026 at 9:47 PM Daniel Sahlberg < >> [email protected]> wrote: >> >> >> >> Den lör 16 maj 2026 kl 20:07 skrev Nathan Hartman < >> [email protected]>: >> >> > >> >> > On Sat, May 16, 2026 at 12:12 PM <[email protected]> wrote: >> >> >> >> >> >> Author: rinrab >> >> >> Date: Sat May 16 16:12:46 2026 >> >> >> New Revision: 1934265 >> >> >> >> >> >> Log: >> >> >> * INSTALL >> >> >> (cmake): Don't mention that cmake is a new addition "available >> only in trunk" >> >> >> and slightly improve writing style. Add a note that gen-make is >> not needed >> >> >> for tar-balls. >> >> >> >> >> >> Modified: >> >> >> subversion/trunk/INSTALL >> >> >> >> >> >> Modified: subversion/trunk/INSTALL >> >> >> >> ============================================================================== >> >> >> --- subversion/trunk/INSTALL Sat May 16 16:11:51 2026 >> (r1934264) >> >> >> +++ subversion/trunk/INSTALL Sat May 16 16:12:46 2026 >> (r1934265) >> >> >> @@ -1194,9 +1194,8 @@ II. INSTALLATION >> >> >> F. Building using CMake >> >> >> -------------------- >> >> >> >> >> >> - Get the sources, either a release tarball or by checking out >> the >> >> >> - official repository. The CMake build system currently only >> exists in >> >> >> - /trunk and it will be included in the 1.15 release. >> >> >> + Get the sources, either from a release tarball or by >> checking out the >> >> >> + official repository. >> >> >> >> >> >> The process for building on Unix and Windows is the same. >> >> >> >> >> >> @@ -1204,6 +1203,9 @@ II. INSTALLATION >> >> >> $ cmake -B out [build options] >> >> >> $ cmake --build out >> >> >> >> >> >> + Note: If you're using the tar-ball distribution, the first >> gen-make step >> >> >> + can be skipped. >> >> >> + >> >> >> "out" in the commands above is the build directory used by >> CMake. >> >> >> >> >> >> Build options can be added, for example: >> >> > >> >> > >> >> > >> >> > Oh, thank you for doing that! >> >> > >> >> > In r1934271 I added a couple of sentences at the start of section E >> >> > (building on Windows) to point out the new CMake build. >> >> > >> >> > In r1934272 I nominated both (as a group) for backport to the 1.15.x >> >> > branch. >> >> > >> >> > Cheers, >> >> > Nathan >> >> > >> >> >> >> You beat me to it! There was one more revision by Timofei and I made a >> >> minor adjustment myself and voted for this all. >> > >> > >> > Thanks guys! >> > >> > I will vote for the backport. Also I guess there are some extra >> nominations that I didn't review yet. >> > >> > Also we currently have that the INSTALL is pretty massive and hard for >> a person to parse. Some stuff there is rather outdated. There are a lot of >> notes about copying random DLLs, etc. I think we might consider >> reorganising this document. For example, make it so we have a primary way >> to approach build that consists of './configure ; make' / 'cmake -B out ; >> cmake --build out' with dependencies from system packages and then go >> through some advanced configurations. I think it would be something that a >> user would most likely first look for. >> >> Yes, that would be really good. The Windows build instructions are a >> mess and I have never quite managed to make them work. I also have a >> strong feeling they are outdated, for example they only Apache Httpd >> 2.0 and 2.2 is still a "FIXME". >> >> Cheers, >> Daniel >> > > > True, INSTALL has grown quite complex and the (non-CMake) Windows > procedure (section E) is known to be dated. > > There was a discussion about this in 2020 where Johan and others shared > notes/corrections [1]. > > Thinking out loud: > > Should we remove section E entirely and only document the CMake procedure > for Windows? Maybe for 1.16? > > One good thing about section E is the list of dependencies and required > software. The CMake procedure only mentions Visual Studio and vcpkg--are > those enough to build the whole stack? > > One more thought: it seems many projects like to use Markdown for their > docs nowadays. My only complaint about Markdown: there isn't a definitive > standard; there are different flavors. But putting that aside, would we > want our docs in Markdown format? Would that make them easier to read and > navigate? > > [1] Building SVN (dependencies) on Windows > 20 Apr 2020 > https://lists.apache.org/thread/qf1tfohrwjrjk4qm1j1l8z11hfthlcq3 > > I am +1 to improve or completely rewrite INSTALL. I think we need simple document focused on potential contributors who want to start contributing fixes or improvements. I would suggest to remove instructions how to build dependencies from INSTALL document: - Package manager provided dependencies (apt-get, homebrew, vcpkg etc) are good enough in most cases. - It's hard to maintain build instructions for dependencies since they may change way how to build. -- Ivan Zhakov
