In message <7aa44215-febf-73d2-3d0f-12f99b44b...@openssl.org> on Mon, 19 Mar 2018 11:14:27 +0000, Matt Caswell <m...@openssl.org> said:
matt> matt> matt> On 19/03/18 10:58, Richard Levitte wrote: matt> > Andy has indicated that the rather special construction to get command line C macro definitions and include paths specs collected in one place (*) is perhaps too special and could be handle by parsing CPPFLAGS and extra multiple definitions to get them collected in one spot. matt> > matt> > I have some ideas on how to do that, but wonder if that would be considered a new feature with regards to the beta release (we can stop talking now in that case) or if this would be considered a fix. That will decide if it's even worth an effort. matt> matt> Well what is a "fix" has always been a bit of a grey area. matt> matt> Does the proposed change offer new capabilities to the user that they matt> didn't have before? matt> matt> If the answer is "yes" that tends to indicate a feature. So I'll answer "yes and no", with a bit of explanation. The whole thing with supporting the use of "make variables" with Configure in GNU autoconf style is a new feature, but that's already in, so I count that is already existing capabilities re the beta release. Being able to define macros and include directories via CPPFLAGS is thusly already available... except that for VMS users, we have CPPDEFINES and CPPINCLUDES to deal with the VMS command line syntax. So phrased "being able to define extra C macros and include directories via 'make variables' when configuring", this is not a new capability. However, phrased "being able to define extra C macros and include directories via CPPFLAGS in when configuring", this could be viewed as a new capability. matt> Does the proposed change fix existing capabilities so that they matt> work as originally intended? matt> matt> An answer of "yes" to that tends to indicate a fix. Well, I could say "yes" if the original intent is phrased "CPPFLAGS is used for all C preprocessor flags"... which is the usual intent, at least on platforms with Unix style flags, and considering CPPFLAGS has originated on Unix as far as I know, ... matt> I haven't got a good understanding of the particular change you matt> are proposing to be able to say where in all of this that one matt> fits. The idea I have would affect Configurations/descrip.mms.tmpl more or less entirely, and would be to parse $config{CPPFLAGS}, extract and put aside any macro definitions and include directory specs and put back the rest of what was parsed back in $config{CPPFLAGS}, and use the extracted macro definitions and include directory specs further on, in these lines: DEFINES={- our $defines1 = join('', map { ",$_" } @{$config{CPPDEFINES}}) -} INCLUDES={- our $includes1 = join(',', @{$config{CPPINCLUDES}}) -} What happens in practice is that $config{CPPDEFINES} and $config{CPPINCLUDES} would stop existing, and template internal variables would take their place in those two lines. And of course, all traces of CPPDEFINES and CPPINCLUDES would be removed anywhere else... that's mostly config and Configure. Cheers, Richard matt> matt> Matt matt> matt> > matt> > Note: this affects VMS only, at least re make variables. matt> > matt> > Cheers matt> > Richard matt> > matt> > (*) Unix and windows handles those with -D and -I flags that can be spread out all over the command line. VMS command lines work a bit differently, and the C compiler complies with that standard, so *all* macros must be collected in *one* qualifiers (VMS terminology where the Unix guy would say "flag" or possibly "option"), like this: matt> > matt> > /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar") matt> > matt> > The same goes for include paths, similarly collected in the qualifier /INCLUDE matt> > matt> > matt> > Matt Caswell <m...@openssl.org> skrev: (19 mars 2018 10:12:06 CET) matt> >> matt> >> matt> >> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote: matt> >>> Hi, matt> >>> matt> >>> in view of the upcoming beta release and the release strategy (see matt> >>> below) it is a little bit disturbing that our GitHub milestone for matt> >> 1.1.1 matt> >>> <https://github.com/openssl/openssl/milestone/9> shows only 30% matt> >>> completion. How are we going to deal with this? matt> >> matt> >> Up until now, understandably, people have been focusing on getting the matt> >> required features in. My expectation is that, once we're past the beta matt> >> release and new features are no longer allowed for 1.1.1, focus will matt> >> shift to closing off as many of the open issues/PRs as possible. matt> >> matt> >>> Shouldn't the PR's and matt> >>> issues be examined and categorized into bugs and features? The former matt> >>> could still be merged during beta, but what happens to the latter? matt> >> What matt> >>> is with outstanding documentation (e.g. #5461, #5629), will it be matt> >>> treated like a bugfix and be mergeable past the beta freeze? matt> >> matt> >> Mostly, I think what remains are bugs and not features. If there are matt> >> features then no one cared enough about them to push them forward to matt> >> get matt> >> into 1.1.1 and so we should reclassify them with a post-1.1.1 matt> >> milestone. matt> >> In some exceptional cases, if someone can make a good enough case, we matt> >> might consider merging them during the beta - but that might take an matt> >> omc matt> >> vote, so the case would have to be very strong. matt> >> matt> >> We have always treated missing documentation as a bug so I don't see a matt> >> problem there. matt> >> matt> >> Matt matt> >> matt> >>> matt> >>> Regards, matt> >>> Matthias matt> >>> matt> >>> -- matt> >>> We have defined the following release criteria for 1.1.1: matt> >>> matt> >>> All open github issues/PRs older than 2 weeks at the time of release matt> >> to matt> >>> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 matt> >> milestone matt> >>> to be closed (see below) matt> >>> Clean builds in Travis and Appveyor for two days matt> >>> run-checker.sh to be showing as clean 2 days before release matt> >>> No open Coverity issues (not flagged as "False Positive" or "Ignore") matt> >>> TLSv1.3 RFC published matt> >>> https://www.openssl.org/policies/releasestrat.html matt> >>> matt> >>> matt> >>> _______________________________________________ matt> >>> openssl-project mailing list matt> >>> openssl-project@openssl.org matt> >>> https://mta.openssl.org/mailman/listinfo/openssl-project matt> >>> matt> >> _______________________________________________ matt> >> openssl-project mailing list matt> >> openssl-project@openssl.org matt> >> https://mta.openssl.org/mailman/listinfo/openssl-project matt> > matt> _______________________________________________ matt> openssl-project mailing list matt> openssl-project@openssl.org matt> https://mta.openssl.org/mailman/listinfo/openssl-project matt> _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project