> > >> > 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? > > > > Given that CMake has not been even an option in any previous release, nor > have we – as far as I'm aware – formally decided to make it the default > build on Windows: it would be appropriate to keep it "experimental but > recommended" for at least one full release cycle. > > I agree with you Branko. I think 1.17 should be the time when we remove vcnet. So it's still an option that needs documentation.
> 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? > > > I can't be sure but they should be. FWIW, vcpkg could be used with the old > vcxproj generator, too. > > Can we maybe make it another chapter then? > > 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? > > > You have to process Markdown, then read it with some non-text display > tool. Unformatted, it's harder to read than plain text. > > You can still read it as plain text. We could still wrap paragraphs and add fancy whitespaces in places we want them to be. But I would prefer if we kept the plaintext style just for the sake of the spirit. -- Timofei Zhakov
