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: