On Sun, 17 Jan 2010, Craig Silverstein wrote:

> I do something similar to this for projects I write that have to
> compile under windows (MSVC or nmake).  However, instead of this
> approach:
> 
> } Instead of touching the Unix config.h file, a dedicated winconfig.h file 
> } is introduced, and all the instances of:
> }
> } #ifdef HAVE_CONFIG_H
> } #include "config.h"
> } #endif
> }
> } are replaced with:
> }
> } #include "sysconfig.h"
> 
> which is prety invasive, I do the following:

In terms of the current patch payload, yes. In terms of resulting lines of 
code, no.
In general terms, I'd rather keep all the ifdef-ish out the main files, 
and isolated into seldomly accessed ones (like the proposed sysconfig.h).



> create a windows directory, and create a version of config.h in the
> windows directory that is basically manually set up (like this patch
> does).  Then, when compiling under windows, I just add
>    -Iwindows
> to the compile line.  This should result in the windows config.h being
> preferred over the top-level config.h.
> 
> I don't see any reason not to do that, though it'll be work to keep
> the windows config.h manually synced with the unix config as changes
> are made to autoconf.ac.  But I believe such changes are pretty rare
> at this point, so maybe it's a good trade-off.
> 
> As for adding in a windows-specific Makefile (the second patch), I
> believe the pcre path is to use cmake rather than nmake, so I don't
> think this adds very much.  (And maybe cmake automatically makes a
> config.h?  What do windows developers do nowadays?)  What would be
> more useful I think, if we don't already have it, would be a .sln and
> .vcproj files, for building under MSVC.  But I don't actually develop
> in windows, so I don't know.  Come to think of it, I'm probably not
> the right person to ask...

>From a standpoint of Unix developers/maintainers w/out having access to MS 
tools, I'm not sure this is a good idea.
Using a makefile.win allows to Windows developers that owns MSVC, to 
simply run the supplied and MSVC-default nmake, while allows Unix 
developers/maintainers to simply edit a text file.
Anyway, whatever method you guys choose, it'd be good to have a way to 
build PCRE on Windows w/out installing extra software (like cmake).



- Davide



-- 
## List details at http://lists.exim.org/mailman/listinfo/pcre-dev 

Reply via email to