Re: MSVC 2017+ Toolset Support

--===============9036850824976941683==
Content-Type: multipart/alternative; boundary="000000000000a4744d05ac9e6e13"

--000000000000a4744d05ac9e6e13
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 11, 2020 at 2:06 PM Bill Deegan <bill-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org>
wrote:

> Am I grossly mistaken, or would separate variables as I've proposed above
> also allow specifying as explicitly as the single string which needs to be
> regex'd?
>

You are not mistaken.

Multiple variables are certainly possible. However, they are more difficult
to reconcile and validate for consistency and in general more verbose from
an end-user perspective.

That said, the current regex and validation/verification is simply an
interface to map a user specification to an internal representation.
There's no reason an alternate user-facing interface cannot be adopted
(other then catching the author on a bad day).  A combination of
toolset/product/component (some or all of which are optional), while more
difficult to validate and reconcile, could certainly be mapped into the
same internal data structures.

What may not be obvious from the regex is that it does not allow a product
type (component) without being attached to a toolset and/or product.  Not
sure if this is desirable or not.  If it is desireable, then the search
algorithm would almost certainly have to be expanded likely with an
additional table with a different ranking scheme.

Admittedly, have not put much thought into that particular scenario.

--000000000000a4744d05ac9e6e13
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Aug 11, 2020 at 2:06 PM Bill Deegan &lt;<a href=3D"mailto:bi=
ll-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org">bill-cJFiu+DHMVC5azolltMz9laTQe2KTcn/@public.gmane.org</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Am =
I grossly mistaken, or would separate variables as I&#39;ve proposed above =
also allow specifying as explicitly as the single string which needs to be =
regex&#39;d?</div></div></blockquote><div><br></div><div>You are not mistak=
en.</div><div><br></div><div>Multiple variables are certainly possible. How=
ever, they are more difficult to reconcile and validate for consistency and=
 in general more verbose from an end-user perspective.</div><div><br></div>=
<div><div>That said, the current regex and validation/verification is simpl=
y an interface to map a user specification to an internal representation.=
=C2=A0 There&#39;s no reason an alternate user-facing interface cannot be a=
dopted (other then catching the author on a bad day).=C2=A0 A combination o=
f toolset/product/component (some or all of which are optional), while more=
 difficult to validate and reconcile, could certainly be mapped into the sa=
me internal data structures.</div></div><div><br></div><div>What may not be=
 obvious from the regex is that it does not allow a product type (component=
) without being attached to a toolset and/or product.=C2=A0 Not sure if thi=
s is desirable or not.=C2=A0 If it is desireable, then the search algorithm=
 would=C2=A0almost certainly have to be expanded likely with an additional =
table with a different ranking scheme.</div><div><br></div><div>Admittedly,=
 have not put much thought into that particular scenario.</div></div></div>

--000000000000a4744d05ac9e6e13--

--===============9036850824976941683==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev

--===============9036850824976941683==--