Bill, William A. Rowe, Jr. schrieb: > Guenter Knauf wrote: >> what two different copies? where are these two? > > There were two flavors of the instructions for netware, one occurred > before and one after the section on rebuilding docs. whoups?
>>> It is not clear ... gmake or make? make -f NWGNUftp-makefile will or >>> will not work properly? Netware eyeballs requested. >> GNU make, may it called gmake or make (but I think in main httpd docs we >> speak about gmake, so we should be consistent with this); > > +1, and from below, it looks like the right one is retained... will revise soon unless you beat me :) >> and no - '[g]make -f NWGNUftp-makefile' does NOT work due to our >> somewhat strange build system; therefore renaming to NWGNUmakefile IS >> mandatory, and brings up the Q again to rename it already in mod_ftp SVN >> as I did a while ago - but you were not fine with it because you thought >> it would break in-tree build, and I renamed back; but also pointed out >> that its NOT possible to do an in-tree build in such a simple way as >> just copying into the tree + there are no benefits to build in-tree >> because we anyway dont have the tools on Win32 (our build platform) to >> regenerate the docs properly so that the links to mod_ftp are worked in >> - or am I missing something here? > > Right, but anyone combining the packages into a single source would clobber Why would anyone do this? 1) I made clear *and* documented that this is *not* supported nor gives any benefit. 2) If anyone would do so he would most likely be on Win32 where you get a warning and you have to agree before an existing file is overwritten. 3) If anyone would really want to combine into httpd sources then this would certainly be a developer who is skilled enough to realize that the root makefile is useless, and instead its required to modify httpd's ./modules/NWGNUmakefile to include the ftp subdirectory + merge the install part of mod_ftp's makefile into the httpd root NWGNUmakefile - though I wonder who would do this all for zero benefit? > one or more of the NWGNUmakefile's that exist in the root; which is more > than likely the first, httpd's. So for safety's sake, I'm trying to be > consistent (and fix some win32 inconsistencies here, as well). I have no energy to further convince you, and dont care anymore about the naming of the root makefile; though it was crazy when two others who built mod_ftp in the past asked me: Q: why do we need to rename the makefile? A: because the httpd build system expects a NWGNUmakefile. Q: Why is it then not directly named NWGNUmakefile? A: Because it would clash with httpd's NWGNUmakefile when you copy everything over into httpd source tree in order to do in-tree build. Q: But the README states that in-tree is not supported nor of any benefit - so why should I try this at all? A: ??? /me not knowing what to answer :) > FWIW, if the top level makefile referred to itself as $(MAKEFILE), perhaps > this could be made to work in the future, having an arbitrary root makefile > name? Not that it's necessarily worth investing a lot of time in. The NetWare build system is not optimal, and neither Brad nor I developed it since we had no time these days - we had enough trouble with getting familar with the new compiler, and only used the GUI with project files; when Novell started to ship Apache 2.0 they needed to have a commandline build process which could be easily adapted for different build hosts and drive names, and so Novell India developed the build system. What I did in the past was fixing things as good as possible, but if I would have enough time I would really write something else from the scratch which looks more clear. However, if I would write something new from the scratch then I would probably consider going with OpenWatcom or gcc. Maybe we can look into a OpenWatcom build system for httpd HEAD - it could then build at least Win32 and NetWare targets, and probably also OS/2 (Brian?) ... Also would be a great thing if we could put the object files of each directory into a makefile.inc which could then be included from all platforms - this would simplify future changes a lot, and reduces maintainance. Günter.
