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

David Gibson <[email protected]> Thu, 29 Sep 2016 10:21:22 +1000
Newsgroups	org.ozlabs.lists.ccan
Message-ID	<20160929002122.GK18880@umbus>
On Wed, Sep 28, 2016 at 12:28:03AM -0600, Kevin Locke wrote:
> On Tue, 2016-09-27 at 15:23 +1000, David Gibson wrote:
> > On Thu, Sep 22, 2016 at 09:33:03PM -0600, Kevin Locke wrote:
> >> 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.
> > 
> > Thanks for sending again.  I've applied a number of the simpler ones
> > already.  The remainder I still have some comments on.
> 
> Thanks for reviewing again!  I think I've addressed everything, but if
> there is anything I've overlooked, let me know.

Right.  Can you rebase your current patches and post them as a new
series.  That's makes my life easier compared to updated versions of
each patch in various places in the thread.

> 
> > 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).
> 
> That is a good point and probably deserves some more thought and
> discussion.  I've tried to keep most additions configurable at
> run-time (e.g. the new -O configurator flag) so if the compile-time
> deduction is wrong it can be overridden.  But it still changes the
> configurator behavior based on how it was compiled without any
> explicit configuration.  That may or may not be desirable.

I think it's desirable, on the whole.  But having overrides is
generally a good idea too.

> Has there
> been any discussion of being more explicit about specifying build vs
> host system at build time?  Anything in particular you have in mind?

No, I'm afraid not.

> A good example of something which can not be overridden at runtime is
> the directory separator passed to popen(3).  I don't think there are
> currently any problems, but the choice of directory separator could
> easily cause problems between Cygwin and native binaries in other
> situations.  Definitely worth thinking about.

Yeah.

-- 
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

_______________________________________________
ccan mailing list
[email protected]
https://lists.ozlabs.org/listinfo/ccan
signature.asc (application/pgp-signature, 819 B)