[ccan] [PATCH v2 00/13] configurator: Support for Windows and MSVC

David Gibson david at gibson.dropbear.id.au
Tue Sep 27 15:23:42 AEST 2016


On Thu, Sep 22, 2016 at 09:33:03PM -0600, Kevin Locke wrote:
> Hi all,
> 
> This is the second revision of my patch series which adds support for
> building configurator with Microsoft Visual C++ and running it on
> Windows.  The motivation is to add sufficient support for Windows to
> allow using header-only modules with minimal hassle.
> 
> The major change in this revision is the handling of the output cflag,
> which can now be specified by a command-line option to configurator and
> is set in a separate config.h macro.  This both fixes the ccanlint
> breakage in the previous series and preserves backwards-compatibility
> for any code calling configurator or using CCAN_CFLAGS.
> 
> Patches which need special attention:
> 
> As before, patch 3 adds a copy of the err.h functions used by
> configurator to work around the lack of err.h on Windows.  If this is
> too much code to lump into configurator.c, I can split it out (and copy
> err.{c,h} verbatim from musl) or call fprintf+exit directly or consider
> modifying the ccan/err module for use by configurator.
> 
> Patch 8 changes the configurator API by adding a command-line option and
> config.h macro.  The names are different than I had previously
> suggested, as noted in the commit message.
> 
> Patch 13 adds appveyor.yml for AppVeyor CI.  This will require (free)
> account setup on ci.appveyor.com once merged to enable automatic
> building and GitHub integration (if desired).  You may also wish to
> consider whether to add a README badge or email notification or other
> mechanism to be notified of build status (beyond the default pull
> request hooks).
> 
> Thanks for considering once again,

Thanks for sending again.  I've applied a number of the simpler ones
already.  The remainder I still have some comments on.

Incidentally you are introducing a new concept here which isn't really
comment on.  The use of more #ifdefs on system macros into
configurator means that the way our default compiler options will be
set up is basically going to be dependent on the setup used to compile
configurator itself.

That seems like a sensible approach to me; we just need to be a bit
careful of interactions with make and/or other build systems when we
could have a system with multiple compilation options (e.g. both MSVC
and cygwin/gcc installed on a Windows machine).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/ccan/attachments/20160927/54fe4110/attachment-0001.sig>


More information about the ccan mailing list