This is definitely in the grey area, but I tend to think it is more towards the "fix" side than the "feature" side. Also the risk is significantly mitigated by it only impacting VMS.
Matt On 19/03/18 11:52, Richard Levitte wrote: > In message <[email protected]> on Mon, 19 Mar > 2018 11:14:27 +0000, Matt Caswell <[email protected]> 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 <[email protected]> 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> >>> [email protected] > matt> >>> https://mta.openssl.org/mailman/listinfo/openssl-project > matt> >>> > matt> >> _______________________________________________ > matt> >> openssl-project mailing list > matt> >> [email protected] > matt> >> https://mta.openssl.org/mailman/listinfo/openssl-project > matt> > > matt> _______________________________________________ > matt> openssl-project mailing list > matt> [email protected] > matt> https://mta.openssl.org/mailman/listinfo/openssl-project > matt> > _______________________________________________ > openssl-project mailing list > [email protected] > https://mta.openssl.org/mailman/listinfo/openssl-project > _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
