Topic: Generating old style header files from modules


Author: David Hunter <davidhunter22@gmail.com>
Date: Mon, 26 Oct 2015 09:04:37 -0700 (PDT)
Raw View
------=_Part_2121_417404795.1445875477422
Content-Type: multipart/alternative;
 boundary="----=_Part_2122_1236491364.1445875477422"

------=_Part_2122_1236491364.1445875477422
Content-Type: text/plain; charset=UTF-8

I had asked this question a while
back https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/module/std-proposals/IFo4fbKFwmE/hqNxFp-I-8QJ
but never really got an  answer.
I would post this question onto the SG2 group but that is closed.

I have not been able to find out anywhere, including Gabriel's great
talk https://www.youtube.com/watch?v=RwdQA0pGWa4, whether the intent is to
allow old style header files, and presumably and old style DLL/shared
library, to be
generated from a module. I would love to move our internal development to
use modules as soon as feasible. However clients who use our library may
not be able or willing to consume modules for a while. So if
we can generate headers we can distribute both headers and modules and the
world will be full of joy! This also would possible also address users of
older compilers that don't support modules, although in this case
there are issues around what other newer C++ those compilers don't support
and how you would generate headers that only contain features they do
support.

If generating headers is possible another question then becomes what is the
granularity of those headers and how is that granularity controlled.

I view this issue as quite important to the migration period. If we have to
manually support bother headers and modules, and given the proposals I'm
not even sure how to do that, it would be a huge disincentive for us
and many others in a similar position to migrate internally to modules. So
progress to switching to modules may become tied to the slowest adopter.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2122_1236491364.1445875477422
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I had asked this question a while back=C2=A0https://groups=
..google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/module/s=
td-proposals/IFo4fbKFwmE/hqNxFp-I-8QJ but never really got an =C2=A0answer.=
<div>I would post this question onto the SG2 group but that is closed.</div=
><div><br></div><div>I have not been able to find out anywhere, including G=
abriel&#39;s great talk=C2=A0https://www.youtube.com/watch?v=3DRwdQA0pGWa4,=
 whether the intent is to allow old style header files, and presumably and =
old style DLL/shared library, to be</div><div>generated from a module. I wo=
uld love to move our internal development to use modules as soon as feasibl=
e. However clients who use our library may not be able or willing to consum=
e modules for a while. So if</div><div>we can generate headers we can distr=
ibute both headers and modules and the world will be full of joy! This also=
 would possible also address users of older compilers that don&#39;t suppor=
t modules, although in this case</div><div>there are issues around what oth=
er newer C++ those compilers don&#39;t support and how you would generate h=
eaders that only contain features they do support.</div><div><br></div><div=
>If generating headers is possible another question then becomes what is th=
e granularity of those headers and how is that granularity controlled.</div=
><div><br></div><div>I view this issue as quite important to the migration =
period. If we have to manually support bother headers and modules, and give=
n the proposals I&#39;m not even sure how to do that, it would be a huge di=
sincentive for us</div><div>and many others in a similar position to migrat=
e internally to modules. So progress to switching to modules may become tie=
d to the slowest adopter. =C2=A0</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2122_1236491364.1445875477422--
------=_Part_2121_417404795.1445875477422--

.