On Sat, Dec 3, 2016 at 1:04 PM, Gregg Smith <g...@gknw.net> wrote: > As for I, the only problematic VC IDE is 10 because it simply refuses to > recognize /implib which is a baked in bug. Instead it names the import > library the same as the project so all consumers trying to link to > apr-1/libapr-1.lib cannot. The majority of squeaking over the years seems > to be that VC version IIRC. > > Renaming the apr/apu/api projects with -1 seems to fix that problem (and > remove the link warnings about it) last time I had a VC10 on a machine. > Quite frankly now is the time to do this for both 1.6 & 2.0. At such time > as consumers require functions of these versions they can change their > build to use them if, like httpd, they build it inline with their project. >
That would seem to be the least destructive way to transition, especially if CMake is the 'suggested' approach. Feel free to commit that change on 2.0/1.6. I generally don't like disrupting build folks within a major release cycle, but we have precedent here on the autoconf side, and at least waited for a minor bump. The biggest thing for me is that I like to turn features on that are off > (like IPv6, crypto and db connectors). I've scripted it yet I realize it's > easy to do with cmake with a mile long command. I do not like having to > configure each piece and build separately however. Since during new > releases of a certain consumer I have to do at least 6 builds (x86/64 over > 3 different VC versions) this becomes more time consuming and more prone to > error. > Right off the bat, with 1.6, we should enable IPv6 out of the box. You shouldn't have to toggle too much to build crypto or connectors, since they have subordinate build projects, and if something is off we should fix that. The only lingering headache for me is to toggle LIBICONV over APR_ICONV defines, and as you say, a quick patch or awk script solves that. > Steffen of Apache Lounge wants them, he has voiced this a number of times. > I did some homework knowing this would come up again and Steffen is by huge > proportion the largest provider of binaries for Windows. His builds are > used for every link on the httpd projects download page [1][3] and then > some with the exception of Apache Haus. I do not think it's too much of a > problem to keep them, how much time does it take maintaining them with how > little they ever change? [2] > > So -1 to dropping legacy. Since mak/dep are made from dsw/dsp -1 to > removing them as well. > I am certain we agree on the state of APR 1.6, that we will preserve these. I'm strongly -1 to preserving these for APR 2.0. The corresponding Visual Studio is *physically not available*, due to Sun/MS legal outcomes. Since we already required a fixwin32make script to get this into any usable condition, it seems like a fixcmake result files should get us to an actual set of .mak files and solution/project files that aren't fix-pathed. I'm going to explore that and see what can be done. > Gregg > > [1] I know where speaking of apr here but I am looking downstream and I do > not think that is an incorrect thing to do. > [2] I realize 2.0 may be in a bit of disrepair at the moment but there's > time. > > [3]https://www.apachehaus.net/misc/wamps.txt > > > > On 03.12.2016 16:40, William A Rowe Jr wrote: > >> I'm wondering, where do we go on trunk with 2.0 on Windows, >>> now that we can emit solution/project files from CMake, or just >>> straightforward .mak files? It insisting on a local install of CMake >>> all that much of a hassle for the Windows build machine? >>> >> >
