On Sat, Apr 2, 2011 at 11:17 AM, Guenter Knauf <fua...@apache.org> wrote: > Am 02.04.2011 16:59, schrieb Guenter Knauf: >> >> no, something which is kinda /me giving up on teaching configure to do >> it right ..... >> http://people.apache.org/~fuankg/mingw/MWGNUmakefile >> http://people.apache.org/~fuankg/mingw/MWGNUmakefile.inc >> with that makefile you have both static and dynamic within less the time >> than what configure only needs .... :-) >> and honestly I'm thinking this is brobably a better approach since what >> we now did while wasting countless hours is basically exactly same: >> overwrite configure tests manually :-( > > pros: > - fast > - build is 100% in sync with MSVC build (uses same apr.hw etc.)
We do have some sync issues in the short term, but in the long term I much prefer --disable-feature/--enable-feature/--with-supportlib and being able to autodetect some variations to messing around with the .hw file (or creating some other UI for manipulating apr.hw). > - easy to maintain for everyone who's familar with GNU make > - no dependency on Python > - no dependency on MSYS / bash / configure / m4 / ... > > cons: > - extra maintenance of MWGNUmakefile.inc when source files are added or > removed > Negative vibe warning :) Does this create the application build support? (apr-2-config?) Are apr consumers left with adjusting to the third build system to pick up build tools/flags? This use of another build system doesn't bring much happiness here. I see a tremendous value down the road with exactly one build system I can use across all platforms of interest and be able to select feature sets, integrate third-party libraries, point to alternate tools, set custom build flags, or even patch in customizations (okay, hacks) and not have to understand two build systems in order to do that, or have significant work remaining after getting customizations to work on Linux. > the cons can be axed if we would use separate makefile.inc for the configure > builds as well where we list the source files and include these into the > created Makefile ... - then we would in future only maintain changes at one > place = makefile.inc > > one point which made me hack this makefile was to see how long it would take > to create a working makefile which does the job, and that was done within > ~2.5 hours; > the other point is that I see not much sense in letting configure waste a > huge amount of time for various tests which then finally get anyway > overwritten - and if I look at our branches this becomes even worse because > configure runs then twice (once for APR, once for APU) ... It is definitely unfortunate that much of the time consumed by configure is wasted for Windows. But then I guess a lot is wasted for any particular environment. A set of ac_cv_* envvars comes to mind as a nice time saver, whatever the platform.
