I will put all the various emails together regarding the WIN32 build issues that I am having.
>> >> 1) AWK is necessary and my AWK from Cygwin crashes everytime it is >> used. My Cygwin installation is up to date with the latest edition. >Sorry, then patch cyg-awk, or use another (see win_compling.html). I never >expect Cyg tools to run except within the Cyg shell. Ok can do that. >> 2) Everything within the VC++ application is stored within in their >> respective DEBUG directories. With so many pieces now debugging has become >> very difficult. You cannot simply move the DLL since then the debugger >> becomes confused. >No, if you make makefile.win, or launch the InstallBin target, they work. To be very frank here, if the DSW and DSP are there nobody uses the makefile.win. And to debug I will need to load up all of the DLL's which adds quite a bit of work especially since there are so many modules. >> 3) To set breakpoints the DLL's have to pre-loaded into the debug space, >> otherwise you get a constant error of breakpoint not being able to set. >You can't do this without distributing the .opt file that corresponds to the >.dsw file. You can't do this, since .opt is localized to your machine paths. The problem still is that I have to setup everything to be able to debug. I would much more prefer if it went back to the old way of compilation where everything is in one DLL. This makes debugging and the likes much easier. >> My suggestion is to create a project for building versions of Apache that >> people can use to build production capable releases. But for the debug >> crowd there is a simple project that is like the previous Apache build, >> where you loaded one project, hit build, set a breakpoint and debugged your >> sources. >> >> I can do this if so desired. >This is why I do _exactly_ that with the 'InstallBin.dps' makefile.mak project. >You are then debugging binaries deposited into your 'installed server'. We >can look at exactly what can be toggled, but this should be trivial. >I wish the .opt debugging info were global, unfortunately, it is not. Ok point taken, but could we then change the other project back to what it was before the millions of modules? At 12:51 21/01/2002 -0800, [EMAIL PROTECTED] wrote: >On Mon, 21 Jan 2002, Christian Gross wrote: > > > I think it is great that all of the modules are dynamically loaded in the > > latest builds of Apache. But there is a problem, in that the dependencies > > of libhttp.dll have not been altered. Hence when building Apache not > > everything is built and then there are version conflicts, etc, etc. > >What dependencies are missing? When the magic number is updated you must >rebuild all modules - The problem is that when I do a CVS update not everything gets compiled. Then when I attempt to run magic versions are not up to date. Hence I do a clean and rebuild. Then everything works again. > > I update the dependencies, everytime I call a CVS update those changes are > > then wacked. Is it possible to get the dependencies updated? Thanks > >why not submit a patch if you have the problem fixed? All I would really like is to go back to the dsp files of about 1 week ago. >libhttpd.dll runs without any modules. Therefore it's isn't dependent >on them. Correct, but the problem is with conf file. When you run Apache in the dsw file and use the configuration file as given in the docs directory the modules will not load because the initial directory is set to the directory of the apache executable, which is within the debug directory. The reason I am whining a bit is because I just did an update of the Apache sources from the CVS tree and I had to exert quite a bit of effort to get things to work. I find that unlike before I need to do quite a bit of configuration work before anything works. This is unlike the projects from before. So could we go back to the older projects? Christian
