On Sun, Sep 1, 2013 at 6:22 AM, Steffen <[email protected]> wrote:
> You wrote: > .... GUI? I realize that GUI operations may be fine for you and Steffan > and many others, but a build system that requires manual/GUI intervention > is unsuitable for typical release build and packaging requirements..... > > I hope Steffan is me and not Stefan F > Stefan F doesn't mess with Windows as far as I can tell. > > I do for over 10 years “typical release builds” in 12 flavors at > www.apachelounge.com with success and is downloaded by millions , I do > not see your point that it is unsuitable. Indeed I have a few clicks now, > should be easy to make a .bat/powershell to automate. But I do not want > that, I want no silence building. Btw: In fact there are one click > scripts around (and mentioned here on the list) and I can recall Pierre > Joyce who proposed here (no follow up) a new one click build system based > on the PHP way. > We'll never agree on this. You don't have any sort of argument for me nor me for you. (And I have a bit of experience myself with products on Windows that use open source software.) The widely accepted practice is that software products are built and regression tested hands free. If you are successful without that, good for you. > > Btw. With cmake you need a lot more keyboard strokes then the few clicks > with VC GUI, so what is manual [image: Smile] > > I store those keyboard strokes in version control and they are replayed. > Still investigating the compiler/link/other options cmake uses as said in > the other post. In addition to optimization/debug/tracing options, I make > on request special builds for specific hardware/processors and/or windows > versions, oh so easy now. > Yeah, there's a lot to be learned there. > > What do you mean with “package requirement” on Windows I do not know what > to package. Or do you mean integrating with other (commercial) software, > that is no issue here. They just pick up a build from AL and make an > installer around it with their own software. No issues reported by them. > I mean putting all the pieces together, building any sort of deliverable starting with source code -- whatever you deliver to end users. > > Hard to react for me on your other arguments, to technical and mostly > developer versus typical windows user/admin. I understand your points from > a *nix developer point of few, but please understand that we are not > developers but Windows users/admins. Such a discussion can be endless like > *.nix versus Win. > > That you as a developer have problems with Win build system as it now is, > is hardly to believe. A .dsp and makefile file is hardly changed all that > years > We are hand editing artifacts originally generated by a Microsoft product that isn't available for purchase (or from MSDN), that then requires some odd conversions in order to use with modern tools*. In that context, the lack of change in the format is not good. *Doesn't it take more than one level of Visual Studio to get it into something that the most recent versions will use? > and as Gregg said you have to know to find the place where to insert a > line for the build system with a new module. And with a new module dsp, > Gregg and others can pick it up and you have no worry (open source to > help). Off-topic: Coding is an other story, the “if def Win” stuff. I have > a good experience with module developers, in an early stage they hand me > over the code to test it. I remember the old days when mod_fcgid was not > ASF, together with the author we implemented the Win additions/changes. > Also mod_security is handed me over before beta/rc > > I have to say that the Windows community appreciates very much that there > is such attention, there where other days. > > Next week I have time to give cmake a try. Who knows it is not that worse > as it looks like now. > > Regards, > > Steffen > > Ps. > Still strange that you do not want cmake with *nix. > A flexible, non-GUI build that supports a fairly wide range of tools is already implemented for *nix. > > > *From:* Jeff Trawick <[email protected]> > *Sent:* Sunday, 1 September, 2013 05:47 > *To:* Apache HTTP Server Development List <[email protected]> > *Subject:* *********** Re: will anyone build httpd/apr with cmake on > Windows? > > On Sat, Aug 31, 2013 at 10:09 PM, Gregg Smith <[email protected]> wrote: > >> Hi Jeff, >> >> I see Steffen has chimed in and have read the reply as well, but I just >> want to cover a couple points now, I need to ponder on some of your other >> comments. >> >> On 8/31/2013 2:41 PM, Jeff Trawick wrote: >> >>> On Sat, Aug 31, 2013 at 3:53 PM, Gregg Smith <[email protected] <mailto: >>> [email protected]>> wrote: >>> >>> Hi Jeff, >>> >>> Well, putting on my Apache Haus hat my first impressions are "What >>> a nightmare!" :) >>> I must say I prefer the more turnkey approach we enjoy these days, >>> >>> >>> I'm not 100% sure what you mean by the more turnkey approach. I guess >>> that is putting support libraries under httpd/srclib and having the httpd >>> build sort of orchestrate putting the libraries together, installing the >>> stuff httpd cares about, etc? >>> >> >> More the fact that httpd, APR, APU & APIconv are built in one click of >> the build button. Granted, other dependencies have to be built separately >> including now PCRE as of 2.3. >> >> >> Although I do try to work on Windows from time to time, I am no expert in >>> building and putting together stuff in the current way. Here is my own >>> admittedly ignorant understanding of the current build system (please add >>> corrections): >>> >>> * I have to do multiple conversions of the project files in svn to run >>> with the latest Visual Studio stuff >>> >> >> With that obstinate nightmare called VC10, that was the only way I could >> get it to be successful (converting to VC9 first), VC11 this is not the >> case. It still has quirks, the intellinonsense in VC11 is a pain, but as >> long as we regenerate apr/apu.h files during every build, it's going to >> rebuild those a few times during a single build session. I need to look >> again and see if it can be disabled though I doubt it. I've worked around >> it. >> >> As Steffen mentioned, it needs a little minor adjusting to get it >> working. VC11 does not like embedding the manifest in ApacheMonitor, nor >> does it like using precompiled headers in APR-Iconv. For whatever reason >> for me, it cannot find libxml2.lib for mod_proxy_html/xml2enc, even though >> it has no problems with any other modules dependencies . I haven't figured >> this one out yet. I have to build on a VM somewhere in the world and the >> added time/complexity has kept me from getting anywhere fast with this. >> >> >> * Manual and/or Visual Studio GUI work is required to build everything >>> using recent Microsoft tools. >>> >> Huh? Manual? VC GUI yes, because we do not have a full set of nmake >> makefiles in svn, like there are for APR/APU. > > > GUI? I realize that GUI operations may be fine for you and Steffan and > many others, but a build system that requires manual/GUI intervention is > unsuitable for typical release build and packaging requirements. Windows > build support in httpd/apr is defective if it can't be built with modern > Microsoft compilers without manual intervention. That isn't to say, of > course, that GUI ways of doing things are bad or inappropriate for the > projects to provide. (cmake generates project files too, but somebody that > likes to build in the Visual Studio GUI would need to try it and compare.) > > Surely there's a way to script what you're doing? > > > >> >> * I don't understand how to get Makefiles that build things the right way >>> for the latest Microsoft compilers >>> >> What's "the right way?" If you just mean generating the makefiles, yes, >> that is M$ deciding to remove the feature after VC6. >> >> >> * There's a high ratio of gorp to critical information in the Windows >>> build files we maintain in svn, and I feel that I'm going to break >>> something every time I try to the required new gorp in order to add a file >>> or module or whatever to the build for Windows. >>> >> >> Nah, you've done well so far. Granted, there's only a few lines you need >> to concern yourself with mostly. CPP, LINK32 & the Source file stuff at >> the bottom. You handled adding util_fcgi.c to libhttpd with ease it looked! >> >> Adding a module is another story I admit. It's more just knowing what and >> where. There at least are example in the svn of just adding a module. For >> instance http://svn.apache.org/r1436058 >> >> Then there's also the "PING: Windows folks" on dev@ possibility, >> explaining what was added/subtracted/changed that would require an >> adjustment to the build. Someone knowing with commit access would see this >> and gladly make any necessary changes, then again, maybe not. > > > Sometimes I've added things in a way that works, sometimes I've added > things in a way that doesn't. I forgot about adding mod_authnz_fcgi.dsp > and a reference to it, and nobody else picked up on that either (yet). My > recollection is that other people have mixed results too. > > FWIW, the one line it takes to support that module with cmake is > > "modules/aaa/mod_authnz_fcgi.c+I+FastCGI authorizer-based authentication > and authorization" > > (Modules which require extra defines or libraries would have another line > for every special requirement -- include or define or extra library or > prereq.) > > > >> >> >> * People have other build tools on Windows that they want to use, and all >>> that Visual Studio stuff is essentially useless to them except for trying >>> to reverse engineer intention out of the generated gorp; certainly not >>> useful for actually building. (I've only tried "NMake Makefile"-based >>> builds using a mix of 32-bit, 64-bit, Visual Studio 2010 tools, and Visual >>> Studio 2012 tools; I haven't tried non-Microsoft compilers yet.) >>> >> >> What people? What other tools? > > > Considering httpd and apr: > > What people/What other tools on Windows > > various including some that provided patches/autoconf-based build in Cygwin > me + various others including multiple people that provided > patches/autoconf-based build using MinGW > product I've worked on/Intel compiler using modified VC6-exported makefiles > > Code can get better when you check it with more compilers. E.g., > Windows-specific code in httpd and apr has gotten better based on building > with gcc. > > >> >> >> >>> My build requirements that aren't met with the current system: >>> >>> * statically linking third-party modules with the server (e.g., >>> including in libhttpd, editing modules.c) >>> * fine-grained control over which modules are built and which are loaded >>> by default >>> >> >> Who am I to decide just what 3rd party modules my users want to use. Not >> only that, when there is a new version of a module, do I really want to >> rebuild and entire Apache? No, I just build the new version of the module. >> That way if Joe User doesn't want mod_auth_ntlm, he doesn't have to >> download it and add it to his Apache and it doesn't have to be absorbing >> space on the hard drive. I do understand this ability is possible in the >> unix build though, I've built on Linux a couple times. >> >> I really do get it and the admin whos corporate policy is to download >> only from ASF or build it in house could have use for this. > > > FWIW, that's not something you do with mod_php or such. One particular > case: it can be useful to augment the core server with additional code, and > organizing it as a statically linked module gets you most of the > integration points for free. The autoconf-based build had support for that > all long. > > At any rate, I use it, you don't, peace on earth ;) > > >> >> >> * absolutely no requirement to put support libraries in srclib/* >>> >> >> I actually had a php developer ask me why we didn't use just a *single* >> dependency tree; >> >> /deps >> /deps/bin >> /deps/include >> /deps/lib >> >> the only answer I came up with was "because this works!" >> >> >> * ability to build for Windows and various Unixy platforms using the same >>> basic flow >>> >> No comment. >> >> >>> But really, who is going to use this on Windows? Who are the noobs? >>> Developers? >>> >> >> The noobs are Joe Windows Apache User who one day decides to grab a free >> copy of VC++ Express and give it a whirl. I was that person once long ago >> in the 1.3 days. If only there were express versions back then. >> >> >> >>> Perhaps I'm misunderstanding something, but installing support libraries >>> to the same prefix lets cmake find stuff with zero code, and the intention >>> is to put things in the same prefix anyway, right? If you wanted to put >>> the sources under srclib but still install to the same prefix it still >>> works? >>> >> >> I get it now and that was mostly what I had, my downfall was using -D >> pointing to optional library folders instead of library files (my bad). >> >> >> Somehow I think that a wrapper script/makefiles to put together the >>> independent builds of the various projects is the missing piece to a lot of >>> these concerns. I would have thought that different >>> developers/bundlers/etc. would have their own way to glue things together >>> that makes sense for them, but perhaps some default is needed. >>> >> >> See makefile.win, it's all there. Installs all the mess including any >> optional DLLs to where they belong. > > > I certainly agree with the value of having a makefile/script which pulls > it all together. Tying all the existing Windows build together without > that is about like doing the same with cmake. > > >> >> >> >>> I've never actually "nmake install" any dependency, it's rather >>> useless on Windows. I have to create multiple mod_ssl with >>> different openssl versions so installing openssl would limit that. >>> This might help you understand my suggestion about dependencies :) >>> >>> >>> I guess with the cmake build of httpd you start with these openssl >>> builds or installs (whatever it takes for FindOpenSSL to deal with): >>> >>> \openssl1 >>> \openssl2 >>> \openssl3 >>> >>> You build httpd once using the desired feature set and you specify one >>> of these openssl trees with the cmake settings CMAKE_LIBRARY_PATH/CMAKE_ >>> **INCLUDE_PATH. >>> >>> Rename that first mod_ssl.so mod_ssl_for_openssl1.so >>> >>> Build httpd two more times using minimal feature set (save build time), >>> setting the CMAKE path used to find prereqs to those other builds of >>> openssl. >>> >>> ARGH! I do somewhat similar though, yours just sounds harder. >> >> >> How does that work for you today? How much code gets rebuilt as you >>> prepare the additional mod_ssl builds? >>> >> >> 2 OpenSSL builds in srclib, one named openssl and another named openssl-x >> (x being 098 or 101). Build Apache and Install. Rename the OpenSSL folders, >> change Install folder, rebuild just the few items that actually link to >> OpenSSL, Install again. GUI is handy for this since you can rebuild a >> single project easily. >> >> This is driven mainly because of mod_php, PHP 5.4 links to OSSL 0.9.8 so >> if Apache is built with 1.0.1, it will not start. We offer downgrade zips >> for this purpose. mod_fcgid remedies this problem but some people would >> rather use mod_php. > > > Sorry, but I just gotta say it -- when you write "GUI is handy" I read > "unrepeatable procedure that can't be stored in version control" or, at > best, "hard-to-maintain GUI driver script that presses buttons " Why isn't > something that the computer does for you automatically while you do > something that humans are good at easier than something that requires you > to press buttons at certain points? > > >> >> >> Thanks so much for spending the time!! >>> >> >> No problem, I figured I should give it a whirl. >> >> Gregg >> > > Best wishes! > > > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/ > -- Born in Roswell... married an alien... http://emptyhammock.com/
<<wlEmoticon-smile[1].png>>
