Nmap Development mailing list archives
Re: Cleaning the Win build
From: Fyodor <fyodor () insecure org>
Date: Mon, 18 Apr 2011 15:52:49 -0700
On Thu, Apr 14, 2011 at 03:16:23PM +0200, Gisle Vanem wrote:
When I've tested Nping on Windows, I've been able to compile it just fine, using Visual Studio (the "recommended" way to build on Windows),The VC-Express 2008 is deprecated, so I've read. So I decided to try with VC-Express 2010. There were problems compiling the winfix.cc files.
For what it is worth, I always use VC-Express 2010 to compile Nmap. I just tried it with a fresh svn checkout (e.g. per the instructions at http://nmap.org/book/inst-windows.html#inst-win-source) and it worked fine for me. What errors are you getting?
First we need to lay down some ground-rules for the Win-build. I suggest:
Thanks for sending the suggestions. It is worth noting that most of these aren't really Windows specific.
1. No local-headers should include other local-headers more than one level deep.
It would be interesting to see a map (tree) of the headers as they are now. Reducing header depth sounds desirable in general. The main case I can think of where you want depth is when you want to present a public interface for other modules without them having to get absorbed in the implementation details. So Nmap header files generally just include one nsock or nbase header, and that header includes whatever private headers it needs. I guess one can consider these system headers than local ones. Also, a number of headers files (let's call them #2) require definitions from another header file (#2) in order to work at all. Is it better to just include #2 (with protection defines to ensure they don't get included twice) in #1, or require all other headers to know that they must include #2 first if they are going to include #1? The latter reduces header file depth, but it can make finding a working header file set and order a pain when you have a lot of includes.
2. No local-headers should need to redefine things or define things twice (e.g. *win.h files with '#define HAVE_OPENSSL' in 4 places).
Though keep in mind that we need to be able to build some of the Nmap tree separately. In particular, Nsock and Nbase are used in other projects too (like Ncrack).
3. All system-headers should be included ahead of local ones.
That makes sense. I suppose you would want the "real" system headers, then things like nbase/nsock, than the true locals.
4. There should be only one (hand-edited) config-file in the whole Nmap-src tree. I suggest we name this mswin/config.h.
Again, a challenge is making sure that the likes of Nsock and Nbase can still compile by themselves. But sometimes one hand edited file can generate others. For example, I only change the Nmap version numberi nmap.h, and then the Makefile grabs it from there and propogates it to other places.
5. Do we need for 2 winfix.cc files? Except for the option-stuff (NmapOps/NpingOps), could these be merged and put into libnetutil/?
Yeah, I think it would be better to merge those.
If we can do at least 1-4 in small steps, I would be happy. Comments anyone?
I agree that small steps are preferable for things like this. If you can start with a patch for just one of the issues, it is easier to discuss and integrate. Cheers, Fyodor _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Cleaning the Win build Gisle Vanem (Apr 14)
- Re: Cleaning the Win build David Fifield (Apr 14)
- Re: Cleaning the Win build David Fifield (Apr 18)
- Re: Cleaning the Win build Fyodor (Apr 18)
- Re: Cleaning the Win build Gisle Vanem (Apr 28)
- Re: Cleaning the Win build Fyodor (Apr 28)
- Re: Cleaning the Win build Gisle Vanem (Apr 29)
- Re: Cleaning the Win build David Fifield (Apr 29)
- Re: Cleaning the Win build Gisle Vanem (Apr 28)