------=_Part_293_8853791.1395345422163
Content-Type: text/plain; charset=UTF-8

The C++ standard (as of C++ 11) says nothing about how the entire project
should be handled. In practice, however, we *have to* deal with projects
and components because a single source file is rarely enough, and it is
usually just a huge pain in C++. Just *building* a program in C++ is a
non-trivial task on its own. C++ sources are often accompanied by a lengthy
convoluted build scripts which are non-standard and non-portable. In fact,
to me it has always been one of the main drawbacks of using C++ in practice.

It would be extremely wonderful if you could build a project using any
conforming compiler on any platform with just one button press, or one
command, without having to deal with a bunch of source code files for a
platform where the build scripts provided by the author do not work.

But why does it have to be like this? Is not it possible to standardize the
description of a component? For example, in a form of an XML or a JSON file.

--

---
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_293_8853791.1395345422163
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The C++ standard (as of C++ 11) says nothing about ho=
w the entire project should be handled. In practice, however, we&nbsp;<i>ha=
ve&nbsp;to</i>&nbsp;deal with projects and components because a single sour=
ce file is rarely enough, and it is usually&nbsp;just&nbsp;a huge pain in C=
++. Just&nbsp;<i>building</i>&nbsp;a program in C++ is a non-trivial task o=
n its own. C++ sources are often accompanied by a lengthy convoluted build =
scripts which are non-standard and non-portable. In fact, to me it has alwa=
ys been one of the main drawbacks of using C++ in practice.</div><div><br><=
/div><div>It would be extremely wonderful if you could build a project usin=
g any conforming compiler on any platform with just one button press, or on=
e command, without having to deal with a bunch of source code files for a p=
latform where the build scripts provided by the author do not work.</div><d=
iv><br></div><div>But why does it have to be like this? Is not it possible =
to standardize the description of a component? For example, in a form of an=
 XML or a JSON file.</div><div><br></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_293_8853791.1395345422163--

.

Em qui 20 mar 2014, =E0s 12:57:02, Dmitry Akimov escreveu:
> But why does it have to be like this? Is not it possible to standardize t=
he=20
> description of a component? For example, in a form of an XML or a JSON
> file.

It's possible to standardise that. But it wouldn't be the C++ standard. The=
re=20
can be a separate standard.

Also, please be mindful of https://xkcd.com/927/

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

--001a11c22590a191d004f50f81d5
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 20, 2014 at 8:57 PM, Dmitry Akimov <akimov.dima@gmail.com>wrote:

> The C++ standard (as of C++ 11) says nothing about how the entire project
> should be handled.
>

 The standard specifies how a translation unit is formed from source files,
and how a program is formed from a set of translation units.  How include
directives are resolved is implementation-defined, and likewise how the
translation units of a program are specified is implementation-defined.

There is a great diversity in existing practice in this area.  The concept
of libraries (sets of headers and translation units shared between
programs), and the concept of dynamic loading of translation units, are
unspecified by the standard.  Each platform and framework does it
differently, if it does it at all.

There is also work on-going on a Modules feature that will have large
ramifications in this area.

I agree it would be nice to have a standard universal build and packaging
system for standard C++ programs and standard C++ libraries, but given the
existing diversity, I don't see how we can get there from here.

--

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

--001a11c22590a191d004f50f81d5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 20, 2014 at 8:57 PM, Dmitry Akimov <span dir=3D"ltr">&lt;<a href=3D=
"mailto:akimov.dima@gmail.com" target=3D"_blank">akimov.dima@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The C++ standard (as o=
f C++ 11) says nothing about how the entire project should be handled.</div=
></div>
</blockquote><div><br></div><div>=A0The standard specifies how a translatio=
n unit is formed from source files, and how a program is formed from a set =
of translation units. =A0How include directives are resolved is implementat=
ion-defined, and likewise how the translation units of a program are specif=
ied is implementation-defined.</div>
<div><br></div><div>There is a great diversity in existing practice in this=
 area. =A0The concept of libraries (sets of headers and translation units s=
hared between programs), and the concept of dynamic loading of translation =
units, are unspecified by the standard. =A0Each platform and framework does=
 it differently, if it does it at all.</div>
<div><br></div><div>There is also work on-going on a Modules feature that w=
ill have large ramifications in this area.</div><div><br></div><div>I agree=
 it would be nice to have a standard universal build and packaging system f=
or standard C++ programs and standard C++ libraries, but given the existing=
 diversity, I don&#39;t see how we can get there from here.</div>
<div><br></div></div></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 />

--001a11c22590a191d004f50f81d5--

.

On 2014-03-20 15:57, Dmitry Akimov wrote:
> The C++ standard (as of C++ 11) says nothing about how the entire project
> should be handled. In practice, however, we *have to* deal with projects
> and components because a single source file is rarely enough, and it is
> usually just a huge pain in C++. Just *building* a program in C++ is a
> non-trivial task on its own. C++ sources are often accompanied by a lengthy
> convoluted build scripts which are non-standard and non-portable. In fact,
> to me it has always been one of the main drawbacks of using C++ in practice.
>
> It would be extremely wonderful if you could build a project using any
> conforming compiler on any platform with just one button press, or one
> command, without having to deal with a bunch of source code files for a
> platform where the build scripts provided by the author do not work.
>
> But why does it have to be like this? Is not it possible to standardize the
> description of a component? For example, in a form of an XML or a JSON file.

Have you *looked* at any build systems lately? Given the complexity of
projects such as autotools, CMake, scons, etc., I'm quite certain that
building projects is a sufficiently complicated project that trying to
create a standardized solution from scratch is going to be enormously
difficult.

And also inappropriate I think, since non-trivial projects often involve
a mixture of "languages" and compile tools (e.g. uic and moc for Qt
projects, rcc on Windows, etc.).

p.s. I can pretty much guarantee that "one button press" will never
happen until a) all projects standardize on a single dependency
information system, b) all operating systems standardize on a package
management system (that must allow per-user packages), and c) the two
are integrated.

See also portage, rpmbuild, etc. which do to some extent solve this
problem... for their own operating systems...

--
Matthew

--

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

.

--001a113488846c5a7c04f51a1fdf
Content-Type: text/plain; charset=ISO-8859-1

Although not a standard, the http://ryppl.org/  project (not sure if it is
still ongoing) has/had some overlap with this.


On Thu, Mar 20, 2014 at 8:22 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2014-03-20 15:57, Dmitry Akimov wrote:
>
>> The C++ standard (as of C++ 11) says nothing about how the entire project
>> should be handled. In practice, however, we *have to* deal with projects
>>
>> and components because a single source file is rarely enough, and it is
>> usually just a huge pain in C++. Just *building* a program in C++ is a
>>
>> non-trivial task on its own. C++ sources are often accompanied by a
>> lengthy
>> convoluted build scripts which are non-standard and non-portable. In fact,
>> to me it has always been one of the main drawbacks of using C++ in
>> practice.
>>
>> It would be extremely wonderful if you could build a project using any
>> conforming compiler on any platform with just one button press, or one
>> command, without having to deal with a bunch of source code files for a
>> platform where the build scripts provided by the author do not work.
>>
>> But why does it have to be like this? Is not it possible to standardize
>> the
>> description of a component? For example, in a form of an XML or a JSON
>> file.
>>
>
> Have you *looked* at any build systems lately? Given the complexity of
> projects such as autotools, CMake, scons, etc., I'm quite certain that
> building projects is a sufficiently complicated project that trying to
> create a standardized solution from scratch is going to be enormously
> difficult.
>
> And also inappropriate I think, since non-trivial projects often involve a
> mixture of "languages" and compile tools (e.g. uic and moc for Qt projects,
> rcc on Windows, etc.).
>
> p.s. I can pretty much guarantee that "one button press" will never happen
> until a) all projects standardize on a single dependency information
> system, b) all operating systems standardize on a package management system
> (that must allow per-user packages), and c) the two are integrated.
>
> See also portage, rpmbuild, etc. which do to some extent solve this
> problem... for their own operating systems...
>
> --
> Matthew
>
>
> --
>
> --- 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/.
>



--
Rui Pires -- http://sennin.pt

--

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

--001a113488846c5a7c04f51a1fdf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Although not a standard, the <a href=3D"http://ryppl.org/"=
>http://ryppl.org/</a> =A0project (not sure if it is still ongoing) has/had=
 some overlap with this.</div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">

On Thu, Mar 20, 2014 at 8:22 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@us=
ers.sourceforge.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

<div class=3D"">On 2014-03-20 15:57, Dmitry Akimov wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"">
The C++ standard (as of C++ 11) says nothing about how the entire project<b=
r></div>
should be handled. In practice, however, we *have to* deal with projects<di=
v class=3D""><br>
and components because a single source file is rarely enough, and it is<br>=
</div>
usually just a huge pain in C++. Just *building* a program in C++ is a<div =
class=3D""><br>
non-trivial task on its own. C++ sources are often accompanied by a lengthy=
<br>
convoluted build scripts which are non-standard and non-portable. In fact,<=
br>
to me it has always been one of the main drawbacks of using C++ in practice=
..<br>
<br>
It would be extremely wonderful if you could build a project using any<br>
conforming compiler on any platform with just one button press, or one<br>
command, without having to deal with a bunch of source code files for a<br>
platform where the build scripts provided by the author do not work.<br>
<br>
But why does it have to be like this? Is not it possible to standardize the=
<br>
description of a component? For example, in a form of an XML or a JSON file=
..<br>
</div></blockquote>
<br>
Have you *looked* at any build systems lately? Given the complexity of proj=
ects such as autotools, CMake, scons, etc., I&#39;m quite certain that buil=
ding projects is a sufficiently complicated project that trying to create a=
 standardized solution from scratch is going to be enormously difficult.<br=
>


<br>
And also inappropriate I think, since non-trivial projects often involve a =
mixture of &quot;languages&quot; and compile tools (e.g. uic and moc for Qt=
 projects, rcc on Windows, etc.).<br>
<br>
p.s. I can pretty much guarantee that &quot;one button press&quot; will nev=
er happen until a) all projects standardize on a single dependency informat=
ion system, b) all operating systems standardize on a package management sy=
stem (that must allow per-user packages), and c) the two are integrated.<br=
>


<br>
See also portage, rpmbuild, etc. which do to some extent solve this problem=
.... for their own operating systems...<span class=3D"HOEnZb"><font color=3D=
"#888888"><br>
<br>
-- <br>
Matthew</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Rui Pires -- <a href=3D"http://sennin.pt" target=3D"_blank">http://sennin.p=
t</a>
</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 />

--001a113488846c5a7c04f51a1fdf--

.

------=_Part_1031_12408076.1396090525171
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


>
> It's possible to standardise that. But it wouldn't be the C++ standard.


Why? What kind of inherent problem prevents us from standardizing the=20
description of a component rather than a single code file?

Could you provide a *rational* explanation?

In the end, the real output of a programming language is a component. A=20
single code file is rarely useful.

I have created the new topic for this:=20
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/n0Mn-8t0=
Lxw Sorry,=20
I had trouble with the UX of Google Groups.

On Friday, March 21, 2014 12:16:45 AM UTC+4, Thiago Macieira wrote:
>
> Em qui 20 mar 2014, =C3=A0s 12:57:02, Dmitry Akimov escreveu:=20
> > But why does it have to be like this? Is not it possible to standardize=
=20
> the=20
> > description of a component? For example, in a form of an XML or a JSON=
=20
> > file.=20
>
> It's possible to standardise that. But it wouldn't be the C++ standard.=
=20
> There=20
> can be a separate standard.=20
>
> Also, please be mindful of https://xkcd.com/927/=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;">It's possible to standardise =
that. But it wouldn't be the C++ standard.</blockquote><div><br></div><div>=
Why? What kind of inherent problem prevents us from standardizing the descr=
iption of a component rather than a single code file?</div><div><br></div><=
div>Could you provide a <i>rational</i> explanation?</div><div><br></div><d=
iv>In the end, the real output of a programming language is a component. A =
single code file is rarely useful.</div><div><br></div><div>I have created =
the new topic for this:&nbsp;<a href=3D"https://groups.google.com/a/isocpp.=
org/forum/#!topic/std-proposals/n0Mn-8t0Lxw">https://groups.google.com/a/is=
ocpp.org/forum/#!topic/std-proposals/n0Mn-8t0Lxw</a>&nbsp;Sorry, I had trou=
ble with the UX of Google Groups.</div><br>On Friday, March 21, 2014 12:16:=
45 AM UTC+4, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">Em qui 20 mar 2014, =C3=A0s 12:57:02, Dmitry Akimov escreveu:
<br>&gt; But why does it have to be like this? Is not it possible to standa=
rdize the=20
<br>&gt; description of a component? For example, in a form of an XML or a =
JSON
<br>&gt; file.
<br>
<br>It's possible to standardise that. But it wouldn't be the C++ standard.=
 There=20
<br>can be a separate standard.
<br>
<br>Also, please be mindful of <a href=3D"https://xkcd.com/927/" target=3D"=
_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A=
%2F%2Fxkcd.com%2F927%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHutHG3HTO1LGoS6q=
bLOY2PCPCtmw';return true;" onclick=3D"this.href=3D'https://www.google.com/=
url?q\75https%3A%2F%2Fxkcd.com%2F927%2F\46sa\75D\46sntz\0751\46usg\75AFQjCN=
HutHG3HTO1LGoS6qbLOY2PCPCtmw';return true;">https://xkcd.com/927/</a>
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></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_1031_12408076.1396090525171--

.

------=_Part_665_20865994.1396091066852
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


>
> There is a great diversity in existing practice in this area.  The concep=
t=20
> of libraries (sets of headers and translation units shared between=20
> programs), and the concept of dynamic loading of translation units, are=
=20
> unspecified by the standard.  Each platform and framework does it=20
> differently, if it does it at all.


Exactly, and this is a huge pain. Actually, it is not the platform that=20
=E2=80=9Cdoes it differently=E2=80=9D, it is the poor *programmer* who has =
to go through=20
the circles of Hell to compile a program on a platform which does not=20
support the supplied makefiles.
=20

> I agree it would be nice to have a standard universal build and packaging=
=20
> system for standard C++ programs and standard C++ libraries, but given th=
e=20
> existing diversity, I don't see how we can get there from here.


Well, we can remove the unneeded diversity. This is the point of=20
standardization, isn't it?

Although it may be not that obvious for most C/C++ developers, but=20
compilation is actually *not* supposed be something nontrivial.

The mentioned diversity and complexity is just a consequence of currently=
=20
used approaches. It does not have to be this way.


On Friday, March 21, 2014 12:20:54 AM UTC+4, Andrew Tomazos wrote:
>
> On Thu, Mar 20, 2014 at 8:57 PM, Dmitry Akimov <akimo...@gmail.com<javasc=
ript:>
> > wrote:
>
>> The C++ standard (as of C++ 11) says nothing about how the entire projec=
t=20
>> should be handled.
>>
>
>  The standard specifies how a translation unit is formed from source=20
> files, and how a program is formed from a set of translation units.  How=
=20
> include directives are resolved is implementation-defined, and likewise h=
ow=20
> the translation units of a program are specified is implementation-define=
d.
>
> There is a great diversity in existing practice in this area.  The concep=
t=20
> of libraries (sets of headers and translation units shared between=20
> programs), and the concept of dynamic loading of translation units, are=
=20
> unspecified by the standard.  Each platform and framework does it=20
> differently, if it does it at all.
>
> There is also work on-going on a Modules feature that will have large=20
> ramifications in this area.
>
> I agree it would be nice to have a standard universal build and packaging=
=20
> system for standard C++ programs and standard C++ libraries, but given th=
e=20
> existing diversity, I don't see how we can get there from here.
>
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

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

<div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 2=
04); border-left-style: solid; padding-left: 1ex;">There is a great diversi=
ty in existing practice in this area. &nbsp;The concept of libraries (sets =
of headers and translation units shared between programs), and the concept =
of dynamic loading of translation units, are unspecified by the standard. &=
nbsp;Each platform and framework does it differently, if it does it at all.=
</blockquote></div><div><br></div><div>Exactly, and this is a huge pain. Ac=
tually, it is not the platform that =E2=80=9Cdoes it differently=E2=80=9D, =
it is the poor <i>programmer</i> who has to go through the circles of Hell =
to compile a program on a platform which does not support the supplied make=
files.</div><div>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(=
204, 204, 204); border-left-style: solid; padding-left: 1ex;">I agree it wo=
uld be nice to have a standard universal build and packaging system for sta=
ndard C++ programs and standard C++ libraries, but given the existing diver=
sity, I don't see how we can get there from here.</blockquote><div><br></di=
v><div>Well, we can remove the unneeded diversity. This is the point of sta=
ndardization, isn't it?</div><div><br></div><div>Although it may be not tha=
t obvious for most C/C++ developers, but compilation is actually <i>not</i>=
 supposed be something nontrivial.</div><div><br></div><div>The mentioned d=
iversity and complexity is just a consequence of currently used approaches.=
 It does not have to be this way.</div><div><br></div><br>On Friday, March =
21, 2014 12:20:54 AM UTC+4, Andrew Tomazos wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu,=
 Mar 20, 2014 at 8:57 PM, Dmitry Akimov <span dir=3D"ltr">&lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"z73bXzqZgtAJ" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">akimo...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The C++ standard (as o=
f C++ 11) says nothing about how the entire project should be handled.</div=
></div>
</blockquote><div><br></div><div>&nbsp;The standard specifies how a transla=
tion unit is formed from source files, and how a program is formed from a s=
et of translation units. &nbsp;How include directives are resolved is imple=
mentation-defined, and likewise how the translation units of a program are =
specified is implementation-defined.</div>
<div><br></div><div>There is a great diversity in existing practice in this=
 area. &nbsp;The concept of libraries (sets of headers and translation unit=
s shared between programs), and the concept of dynamic loading of translati=
on units, are unspecified by the standard. &nbsp;Each platform and framewor=
k does it differently, if it does it at all.</div>
<div><br></div><div>There is also work on-going on a Modules feature that w=
ill have large ramifications in this area.</div><div><br></div><div>I agree=
 it would be nice to have a standard universal build and packaging system f=
or standard C++ programs and standard C++ libraries, but given the existing=
 diversity, I don't see how we can get there from here.</div>
<div><br></div></div></div></div>
</blockquote></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_665_20865994.1396091066852--

.

--Apple-Mail=_0004C019-27F0-4722-97AF-55A0DB1B8431
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-03-29, at 6:55 PM, Dmitry Akimov <akimov.dima@gmail.com> wrote:

> It's possible to standardise that. But it wouldn't be the C++ standard.
>=20
> Why? What kind of inherent problem prevents us from standardizing the des=
cription of a component rather than a single code file?

Modules are supposed to tackle some definition of "component," but it is su=
re to be narrower in scope than a project.

Most development systems define a project to correspond to a makefile, and =
those can do pretty much anything. Additionally it encapsulates any platfor=
m-specific information, such as what model UART the MCU includes, whether p=
ointers refer to memory segments, how to unroll loops, etc.

There are several reasons the build systems are not portable:

1. Platforms vary too much.
2. Build systems fundamentally fail to attain or maintain portability.
3. Users of supposedly portable build systems fail to configure or maintain=
 the build on various platforms.

The variety of platform differences, and the number of things that can happ=
en in the course of a build, is immense. Hand-wavy proposals won't be taken=
 seriously. If you can bring some order and organization, then kudos.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_0004C019-27F0-4722-97AF-55A0DB1B8431
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03&ndash;29, at 6:55 PM, Dmitry Akimov &lt;<a href=3D"mailto:akimov.d=
ima@gmail.com">akimov.dima@gmail.com</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-wid=
th: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; p=
adding-left: 1ex;">It's possible to standardise that. But it wouldn't be th=
e C++ standard.</blockquote><div><br></div><div>Why? What kind of inherent =
problem prevents us from standardizing the description of a component rathe=
r than a single code file?</div></div></blockquote><div><br></div><div>Modu=
les are supposed to tackle some definition of &ldquo;component,&rdquo; but =
it is sure to be narrower in scope than a project.</div><div><br></div><div=
>Most development systems define a project to correspond to a makefile, and=
 those can do pretty much anything. Additionally it encapsulates any platfo=
rm-specific information, such as what model UART the MCU includes, whether =
pointers refer to memory segments, how to unroll loops, etc.</div><div><br>=
</div><div>There are several reasons the build systems are not portable:</d=
iv><div><br></div><div>1. Platforms vary too much.</div><div>2. Build syste=
ms fundamentally fail to attain or maintain portability.</div><div>3. Users=
 of supposedly portable build systems fail to configure or maintain the bui=
ld on various platforms.</div><div><br></div><div>The variety of platform d=
ifferences, and the number of things that can happen in the course of a bui=
ld, is immense. Hand-wavy proposals won&rsquo;t be taken seriously. If you =
can bring some order and organization, then kudos.</div><div><br></div></di=
v></body></html>

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

--Apple-Mail=_0004C019-27F0-4722-97AF-55A0DB1B8431--

.

On 03/29/2014 12:04 PM, Dmitry Akimov wrote:

> Well, we can remove the unneeded diversity. This is the point of
> standardization, isn't it?

The diversity is often there for a reason.

The most reasonable path forward is to start collecting requirements.

--

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

.

Em s=E1b 29 mar 2014, =E0s 03:55:25, Dmitry Akimov escreveu:
> > It's possible to standardise that. But it wouldn't be the C++ standard.
>=20
> Why? What kind of inherent problem prevents us from standardizing the
> description of a component rather than a single code file?
>=20
> Could you provide a *rational* explanation?

Because the C++ Language standard defines, as the name says, the C++ Langua=
ge.=20
If your project description is written in a different language, then it's n=
ot=20
the C++ Language.

Unless you're proposing a way to define this *inside* the C++ Language. In =
that=20
case, I really recommend you interact with the study group looking into=20
Modules first. Please be careful with chicken-and-the-egg problems here.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.