Topic: Standardized project file format
Author: Dmitry Akimov <akimov.dima@gmail.com>
Date: Sat, 29 Mar 2014 03:34:41 -0700 (PDT)
Raw View
------=_Part_132_32983672.1396089281433
Content-Type: text/plain; charset=UTF-8
Is it possible to standardize a C++ project file format, with e.g. XML,
JSON?
So that the whole component could be compiled with a conforming compiler on
any platform, without the need to use non-standard non-portable makefiles,
proprietary IDE project files, etc.
--
---
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_132_32983672.1396089281433
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Is it possible to standardize a C++ project file format, w=
ith e.g. XML, JSON?<div><br></div><div>So that the whole component could be=
compiled with a conforming compiler on any platform, without the need to u=
se non-standard non-portable makefiles, proprietary IDE project files, etc.=
</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" 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_132_32983672.1396089281433--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 29 Mar 2014 15:17:38 -0700
Raw View
Em s=E1b 29 mar 2014, =E0s 03:34:41, Dmitry Akimov escreveu:
> Is it possible to standardize a C++ project file format, with e.g. XML,
> JSON?
>=20
> So that the whole component could be compiled with a conforming compiler =
on
> any platform, without the need to use non-standard non-portable makefiles=
,
> proprietary IDE project files, etc.
If you standardise on anything that is not C++, it's not part of this=20
committee's purview. You're welcome to go ahead and create the auxiliary=20
standard and the C++ committee can even strongly recommend it.
Here's a quick list of things that I feel must be present:
- C and assembly support
though more languages compiling to native would definitely be welcome
- preprocessors and code generators
(bison, yacc, lex/flex, moc, uic, rcc, etc.)
- post-compilation steps (like objcopy)
- linking, including target binary type selection
(dynamic executable, static executable, firmware / kernels,
static libraries, shared libraries, DLLs)
- post-linking steps (strip, objcopy, winres)
And all of that must work with cross-compilers too.
As a second step, please investigate feature-detection, like autoconf and=
=20
cmake.
--=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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Sun, 30 Mar 2014 02:27:31 +0200
Raw View
------W2CBKOFFTZ2FSLGVO7YI6MESM4Z2LI
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
All of this is "almost" equivalent to C++ getting a standardized package ma=
nagement system. I think the original author of the thread is influenced by=
other programming languages who have something like this (will not name th=
em) or eventual C++ competitors who are in the process of developing someth=
ing like this but are also actively developing their own standard library w=
ith facilities that can assist the development of said idea.
The requirements on newer standard library facilities (or even language fea=
tures) for something like this to ever materialize in C++ would likely invo=
lve more SGs. It is unlikely for a single proposal to tackle such a problem=
viably without other SGs getting a bystander involvement. Most importantly=
, as Thiago Macieira said elsewhere on this list, modules.
Thiago Macieira <thiago@macieira.org> wrote:
>Em s=C3=A1b 29 mar 2014, =C3=A0s 03:34:41, Dmitry Akimov escreveu:
>> Is it possible to standardize a C++ project file format, with e.g.
>XML,
>> JSON?
>>=20
>> So that the whole component could be compiled with a conforming
>compiler on
>> any platform, without the need to use non-standard non-portable
>makefiles,
>> proprietary IDE project files, etc.
>
>If you standardise on anything that is not C++, it's not part of this=20
>committee's purview. You're welcome to go ahead and create the
>auxiliary=20
>standard and the C++ committee can even strongly recommend it.
>
>Here's a quick list of things that I feel must be present:
>
>- C and assembly support
> though more languages compiling to native would definitely be welcome
>- preprocessors and code generators
> (bison, yacc, lex/flex, moc, uic, rcc, etc.)
>- post-compilation steps (like objcopy)
>- linking, including target binary type selection
> (dynamic executable, static executable, firmware / kernels,
> static libraries, shared libraries, DLLs)
>- post-linking steps (strip, objcopy, winres)
>
>And all of that must work with cross-compilers too.
>
>As a second step, please investigate feature-detection, like autoconf
>and=20
>cmake.
>--=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 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/.
--=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/.
------W2CBKOFFTZ2FSLGVO7YI6MESM4Z2LI
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">All of this is "almost" equivalent =
to C++ getting a standardized package management system. I think the origin=
al author of the thread is influenced by other programming languages who ha=
ve something like this (will not name them) or eventual C++ competitors who=
are in the process of developing something like this but are also actively=
developing their own standard library with facilities that can assist the =
development of said idea.</p>
<p dir=3D"ltr">The requirements on newer standard library facilities (or ev=
en language features) for something like this to ever materialize in C++ wo=
uld likely involve more SGs. It is unlikely for a single proposal to tackle=
such a problem viably without other SGs getting a bystander involvement. M=
ost importantly, as Thiago Macieira said elsewhere on this list, modules.<b=
r>
</p>
<br><br><div class=3D"gmail_quote">Thiago Macieira <thiago@macieira.org&=
gt; wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.=
8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">Em s=C3=A1b 29 mar 2014, =C3=A0s 03:34:41, Dmitry Aki=
mov escreveu:<br /><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0=
pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Is it po=
ssible to standardize a C++ project file format, with e.g. XML,<br /> JSON?=
<br /> <br /> So that the whole component could be compiled with a conformi=
ng compiler on<br /> any platform, without the need to use non-standard non=
-portable makefiles,<br /> proprietary IDE project files, etc.<br /></block=
quote><br />If you standardise on anything that is not C++, it's not part o=
f this <br />committee's purview. You're welcome to go ahead and create the=
auxiliary <br />standard and the C++ committee can even strongly recommend=
it.<br /><br />Here's a quick list of things that I feel must be present:<=
br /><br />- C and assembly support<br /> though more languages compiling t=
o native would definitely be welcome<br />- preprocessors and code generato=
rs<br /> (bison, yacc, lex/flex,
moc, uic, rcc, etc.)<br />- post-compilation steps (like objcopy)<br />- li=
nking, including target binary type selection<br /> (dynamic executable, st=
atic executable, firmware / kernels,<br /> static libraries, shared librari=
es, DLLs)<br />- post-linking steps (strip, objcopy, winres)<br /><br />And=
all of that must work with cross-compilers too.<br /><br />As a second ste=
p, please investigate feature-detection, like autoconf and <br />cmake.</pr=
e></blockquote></div></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" 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 />
------W2CBKOFFTZ2FSLGVO7YI6MESM4Z2LI--
.
Author: Dmitry Akimov <akimov.dima@gmail.com>
Date: Sun, 30 Mar 2014 09:46:05 +0400
Raw View
--90e6ba1efd4a6ee19304f5cc73be
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
>
> If you standardise on anything that is not C++, it's not part of this
> committee's purview.
>
On one hand, I understand this argument, on the other hand, it is not
completely clear what it means to "be a part of C++". *The bigger part of
the current standard is a description of the standard library* which is not
the language per se. One can view C++ as a programming system, not just
purely the language, and the current standard seemingly supports this by
describing the standard library along with the language.
You're welcome to go ahead and create the auxiliary
> standard and the C++ committee can even strongly recommend it.
Well, if it will not be in the standard, then it is not worth trying,
because people will ignore it, and it will be exactly the xkcd
#927<https://xkcd.com/927/> (the
15 competing standards).
Speaking of the complexity, I do not see why it is necessary to standardize
the complex system when you can just standardize the basics and make it
extensible, given that extensibility is a natural feature of both XML and
JSON.
Defining the full-fledged package management system in the C++ standard
would be an overkill, of course.
I think it would be generally odd to make an argument like this: "We cannot
afford the solution covering all the possible use cases, so we shall
continue covering none" (although people tend to make this sort of
arguments *a lot*).
On Sun, Mar 30, 2014 at 2:17 AM, Thiago Macieira <thiago@macieira.org>wrote=
:
> Em s=E1b 29 mar 2014, =E0s 03:34:41, Dmitry Akimov escreveu:
> > Is it possible to standardize a C++ project file format, with e.g. XML,
> > JSON?
> >
> > So that the whole component could be compiled with a conforming compile=
r
> on
> > any platform, without the need to use non-standard non-portable
> makefiles,
> > proprietary IDE project files, etc.
>
> If you standardise on anything that is not C++, it's not part of this
> committee's purview. You're welcome to go ahead and create the auxiliary
> standard and the C++ committee can even strongly recommend it.
>
> Here's a quick list of things that I feel must be present:
>
> - C and assembly support
> though more languages compiling to native would definitely be
> welcome
> - preprocessors and code generators
> (bison, yacc, lex/flex, moc, uic, rcc, etc.)
> - post-compilation steps (like objcopy)
> - linking, including target binary type selection
> (dynamic executable, static executable, firmware / kernels,
> static libraries, shared libraries, DLLs)
> - post-linking steps (strip, objcopy, winres)
>
> And all of that must work with cross-compilers too.
>
> As a second step, please investigate feature-detection, like autoconf and
> cmake.
> --
> 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
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0Mn-8t0Lxw/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>
--=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/.
--90e6ba1efd4a6ee19304f5cc73be
Content-Type: text/html; charset=ISO-8859-1
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-l=
eft-style:solid;padding-left:1ex"><span style=3D"font-family:arial,sans-ser=
if;font-size:13px">If you standardise on anything that is not C++, it's=
not part of this</span><br style=3D"font-family:arial,sans-serif;font-size=
:13px">
<span style=3D"font-family:arial,sans-serif;font-size:13px">committee's=
purview. </span><br>
</blockquote><div><br></div><div>On one hand, I understand this argument, o=
n the other hand, it is not completely clear what it means to “be a p=
art of C++”. <i>The bigger part of the current standard is a descript=
ion of the standard library</i> which is not the language per se. One =
can view C++ as a programming system, not just purely the language, and the=
current standard seemingly supports this by describing the standard librar=
y along with the language.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><span style=3D"font-size:13px;font-family:a=
rial,sans-serif">You're welcome to go ahead and create the auxiliary<br=
>
</span><span style=3D"font-size:13px;font-family:arial,sans-serif">standard=
and the C++ committee can even strongly recommend it.</span></blockquote><=
div><br></div><div>Well, if it will not be in the standard, then it is not =
worth trying, because people will ignore it, and it will be exactly the <a =
href=3D"https://xkcd.com/927/">xkcd #927</a> (the 15 competing standar=
ds).</div>
<div><br></div><div>Speaking of the complexity, I do not see why it is nece=
ssary to standardize the complex system when you can just standardize the b=
asics and make it extensible, given that extensibility is a natural feature=
of both XML and JSON.</div>
<div><br></div><div>Defining the full-fledged package management system in =
the C++ standard would be an overkill, of course.</div><div><br></div><div>=
I think it would be generally odd to make an argument like this: “We =
cannot afford the solution covering all the possible use cases, so we shall=
continue covering none” (although people tend to make this sort of a=
rguments <i>a lot</i>).</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun,=
Mar 30, 2014 at 2:17 AM, Thiago Macieira <span dir=3D"ltr"><<a href=3D"=
mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Em s=E1b 29 mar 2014, =E0s 03:34:41, Dmitry =
Akimov escreveu:<br>
<div class=3D"">> Is it possible to standardize a C++ project file forma=
t, with e.g. XML,<br>
> JSON?<br>
><br>
> So that the whole component could be compiled with a conforming compil=
er on<br>
> any platform, without the need to use non-standard non-portable makefi=
les,<br>
> proprietary IDE project files, etc.<br>
<br>
</div>If you standardise on anything that is not C++, it's not part of =
this<br>
committee's purview. You're welcome to go ahead and create the auxi=
liary<br>
standard and the C++ committee can even strongly recommend it.<br>
<br>
Here's a quick list of things that I feel must be present:<br>
<br>
- C and assembly support<br>
though more languages compiling to native would=
definitely be welcome<br>
- preprocessors and code generators<br>
(bison, yacc, lex/flex, moc, uic, rcc, etc.)<br=
>
- post-compilation steps (like objcopy)<br>
- linking, including target binary type selection<br>
(dynamic executable, static executable, firmwar=
e / kernels,<br>
static libraries, shared libraries, DLLs)<br>
- post-linking steps (strip, objcopy, winres)<br>
<br>
And all of that must work with cross-compilers too.<br>
<br>
As a second step, please investigate feature-detection, like autoconf and<b=
r>
cmake.<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
Software Architect - Intel Open Source Technology Center<br>
PGP/GPG: 0x6EF45358; fingerprint:<br>
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 535=
8<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0Mn-8t0Lxw/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0Mn-8t0Lxw=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--90e6ba1efd4a6ee19304f5cc73be--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Sun, 30 Mar 2014 14:12:21 +0300
Raw View
This is a multi-part message in MIME format.
--------------020707020202090900030305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 03/30/2014 08:46 AM, Dmitry Akimov wrote:
>
> If you standardise on anything that is not C++, it's not part of this
> committee's purview.
>
>
> On one hand, I understand this argument, on the other hand, it is not
> completely clear what it means to "be a part of C++". /The bigger part
> of the current standard is a description of the standard
> library/ which is not the language per se. One can view C++ as a
> programming system, not just purely the language, and the current
> standard seemingly supports this by describing the standard library
> along with the language.
>
> You're welcome to go ahead and create the auxiliary
> standard and the C++ committee can even strongly recommend it.
>
>
> Well, if it will not be in the standard, then it is not worth trying,
> because people will ignore it, and it will be exactly the xkcd #927
> <https://xkcd.com/927/> (the 15 competing standards).
>
> Speaking of the complexity, I do not see why it is necessary to
> standardize the complex system when you can just standardize the
> basics and make it extensible, given that extensibility is a natural
> feature of both XML and JSON.
>
> Defining the full-fledged package management system in the C++
> standard would be an overkill, of course.
>
> I think it would be generally odd to make an argument like this: "We
> cannot afford the solution covering all the possible use cases, so we
> shall continue covering none" (although people tend to make this sort
> of arguments /a lot/).
>
It would not be an overkill, nor pointless; but it would require a lot
of newer features and facilities to come about together and that
requires meticulous coordination of already available resources
(standard library, language features etc) for the scope of adding newer
ones for processing these "project formats", "packages" or whatever else
a proposal may bring about.
The current standard library would have hard time meeting any of the
prerequisites for "package formats", "project formats", "package
management" (as in available for reuse facilities you would require like
json / xml parsing, network io, build tools etc) right now.
It would be generally odd to make an argument like this: "We should
afford a _*standard*_ solution covering all the possible use cases, but
without considering whether the building blocks are available or not
first and foremost, within the _*standard*_."
--
---
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/.
--------------020707020202090900030305
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 03/30/2014 08:46 AM, Dmitry Akimov
wrote:<br>
</div>
<blockquote
cite="mid:CAMBUait+dx-ba4Kc5-+z7QNM8R84hm5YMGeNBD_rtjV4J+_GRw@mail.gmail.com"
type="cite">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
style="font-family:arial,sans-serif;font-size:13px">If you
standardise on anything that is not C++, it's not part of
this</span><br
style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">committee's
purview. </span><br>
</blockquote>
<div><br>
</div>
<div>On one hand, I understand this argument, on the other hand,
it is not completely clear what it means to “be a part of
C++”. <i>The bigger part of the current standard is a
description of the standard library</i> which is not the
language per se. One can view C++ as a programming system, not
just purely the language, and the current standard seemingly
supports this by describing the standard library along with
the language.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
style="font-size:13px;font-family:arial,sans-serif">You're
welcome to go ahead and create the auxiliary<br>
</span><span
style="font-size:13px;font-family:arial,sans-serif">standard
and the C++ committee can even strongly recommend it.</span></blockquote>
<div><br>
</div>
<div>Well, if it will not be in the standard, then it is not
worth trying, because people will ignore it, and it will be
exactly the <a moz-do-not-send="true"
href="https://xkcd.com/927/">xkcd #927</a> (the 15 competing
standards).</div>
<div><br>
</div>
<div>Speaking of the complexity, I do not see why it is
necessary to standardize the complex system when you can just
standardize the basics and make it extensible, given that
extensibility is a natural feature of both XML and JSON.</div>
<div><br>
</div>
<div>Defining the full-fledged package management system in the
C++ standard would be an overkill, of course.</div>
<div><br>
</div>
<div>I think it would be generally odd to make an argument like
this: “We cannot afford the solution covering all the possible
use cases, so we shall continue covering none” (although
people tend to make this sort of arguments <i>a lot</i>).</div>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote>
It would not be an overkill, nor pointless; but it would require a
lot of newer features and facilities to come about together and that
requires meticulous coordination of already available resources
(standard library, language features etc) for the scope of adding
newer ones for processing these "project formats", "packages" or
whatever else a proposal may bring about.<br>
<br>
The current standard library would have hard time meeting any of the
prerequisites for "package formats", "project formats", "package
management" (as in available for reuse facilities you would require
like json / xml parsing, network io, build tools etc) right now.<br>
<br>
It would be generally odd to make an argument like this: "We should
afford a <u><b>standard</b></u> solution covering all the possible
use cases, but without considering whether the building blocks are
available or not first and foremost, within the <u><b>standard</b></u>."<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------020707020202090900030305--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 30 Mar 2014 11:45:55 -0700
Raw View
Em dom 30 mar 2014, =E0s 09:46:05, Dmitry Akimov escreveu:
> You're welcome to go ahead and create the auxiliary
>=20
> > standard and the C++ committee can even strongly recommend it.
>=20
> Well, if it will not be in the standard, then it is not worth trying,
> because people will ignore it, and it will be exactly the xkcd
> #927<https://xkcd.com/927/> (the
> 15 competing standards).
It will be the 15th standard in any event, regardless of whether you get it=
=20
into the C++ standard or as an auxiliary standard. Especially so if you can=
't=20
cover all possible use-cases, since it will require non-standard extensions=
=20
and other buildsystems to complete the necessary work.
--=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/.
.
Author: Dmitry Akimov <akimov.dima@gmail.com>
Date: Sun, 30 Mar 2014 22:53:38 -0700 (PDT)
Raw View
------=_Part_2240_29117387.1396245218915
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Then I conclude that it is impossible to have the standard project file=20
format in C++.
Cheers.
On Sunday, March 30, 2014 10:45:55 PM UTC+4, Thiago Macieira wrote:
>
> Em dom 30 mar 2014, =C3=A0s 09:46:05, Dmitry Akimov escreveu:=20
> > You're welcome to go ahead and create the auxiliary=20
> >=20
> > > standard and the C++ committee can even strongly recommend it.=20
> >=20
> > Well, if it will not be in the standard, then it is not worth trying,=
=20
> > because people will ignore it, and it will be exactly the xkcd=20
> > #927<https://xkcd.com/927/> (the=20
> > 15 competing standards).=20
>
> It will be the 15th standard in any event, regardless of whether you get=
=20
> it=20
> into the C++ standard or as an auxiliary standard. Especially so if you=
=20
> can't=20
> cover all possible use-cases, since it will require non-standard=20
> extensions=20
> and other buildsystems to complete the necessary work.=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_2240_29117387.1396245218915
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Then I conclude that it is impossible to have the standard=
project file format in C++.<div><br></div><div>Cheers.<br><br>On Sunday, M=
arch 30, 2014 10:45:55 PM UTC+4, Thiago Macieira wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">Em dom 30 mar 2014, =C3=A0s 09:46:05, Dmitry Akimo=
v escreveu:
<br>> You're welcome to go ahead and create the auxiliary
<br>>=20
<br>> > standard and the C++ committee can even strongly recommend it=
..
<br>>=20
<br>> Well, if it will not be in the standard, then it is not worth tryi=
ng,
<br>> because people will ignore it, and it will be exactly the xkcd
<br>> #927<<a href=3D"https://xkcd.com/927/" target=3D"_blank" onmous=
edown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fxkcd.com=
%2F927%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHutHG3HTO1LGoS6qbLOY2PCPCtmw';=
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\75AFQjCNHutHG3HTO1LGoS=
6qbLOY2PCPCtmw';return true;">https://xkcd.com/927/</a>> (the
<br>> 15 competing standards).
<br>
<br>It will be the 15th standard in any event, regardless of whether you ge=
t it=20
<br>into the C++ standard or as an auxiliary standard. Especially so if you=
can't=20
<br>cover all possible use-cases, since it will require non-standard extens=
ions=20
<br>and other buildsystems to complete the necessary work.
<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> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></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" 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_2240_29117387.1396245218915--
.
Author: Brent Friedman <fourthgeek@gmail.com>
Date: Mon, 31 Mar 2014 03:36:29 -0500
Raw View
--001a1135ef16a6858204f5e2f201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
It will be difficult to build a rich set of tools for C++ in the current
state of affairs. Suppose you want to build a simple tool that graphs your
#includes. Today, how is one to get the list of translation units and
#includes directories? Either by supporting some limited subset of existing
project formats or by creating a 16th competing format.
A partial solution which only covers these two issues would still have
great value. Implementations can continue using their proprietary format,
but by providing a way to convert to the standard format we at least have a
place for tools to start working from.
On Mon, Mar 31, 2014 at 12:53 AM, Dmitry Akimov <akimov.dima@gmail.com>wrot=
e:
> Then I conclude that it is impossible to have the standard project file
> format in C++.
>
> Cheers.
>
>
> On Sunday, March 30, 2014 10:45:55 PM UTC+4, Thiago Macieira wrote:
>>
>> Em dom 30 mar 2014, =E0s 09:46:05, Dmitry Akimov escreveu:
>> > You're welcome to go ahead and create the auxiliary
>> >
>> > > standard and the C++ committee can even strongly recommend it.
>> >
>> > Well, if it will not be in the standard, then it is not worth trying,
>> > because people will ignore it, and it will be exactly the xkcd
>> > #927<https://xkcd.com/927/> (the
>> > 15 competing standards).
>>
>> It will be the 15th standard in any event, regardless of whether you get
>> it
>> into the C++ standard or as an auxiliary standard. Especially so if you
>> can't
>> cover all possible use-cases, since it will require non-standard
>> extensions
>> and other buildsystems to complete the necessary work.
>>
>> --
>> 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
>>
>> --
>
> ---
> 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/.
>
--=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/.
--001a1135ef16a6858204f5e2f201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It will be difficult to build a rich set of tools for C++ =
in the current state of affairs. Suppose you want to build a simple tool th=
at graphs your #includes. Today, how is one to get the list of translation =
units and #includes directories? Either by supporting some limited subset o=
f existing project formats or by creating a 16th competing format.<div>
<br></div><div>A partial solution which only covers these two issues would =
still have great value. Implementations can continue using their proprietar=
y format, but by providing a way to convert to the standard format we at le=
ast have a place for tools to start working from.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
Mar 31, 2014 at 12:53 AM, Dmitry Akimov <span dir=3D"ltr"><<a href=3D"m=
ailto:akimov.dima@gmail.com" target=3D"_blank">akimov.dima@gmail.com</a>>=
;</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">Then I conclude that it is =
impossible to have the standard project file format in C++.<div><br></div><=
div>
Cheers.<div><div class=3D"h5"><br><br>On Sunday, March 30, 2014 10:45:55 PM=
UTC+4, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Em do=
m 30 mar 2014, =E0s 09:46:05, Dmitry Akimov escreveu:
<br>> You're welcome to go ahead and create the auxiliary
<br>>=20
<br>> > standard and the C++ committee can even strongly recommend it=
..
<br>>=20
<br>> Well, if it will not be in the standard, then it is not worth tryi=
ng,
<br>> because people will ignore it, and it will be exactly the xkcd
<br>> #927<<a href=3D"https://xkcd.com/927/" target=3D"_blank">https:=
//xkcd.com/927/</a>> (the
<br>> 15 competing standards).
<br>
<br>It will be the 15th standard in any event, regardless of whether you ge=
t it=20
<br>into the C++ standard or as an auxiliary standard. Especially so if you=
can't=20
<br>cover all possible use-cases, since it will require non-standard extens=
ions=20
<br>and other buildsystems to complete the necessary work.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>=A0 =A0Software Architect - Intel Open Source Technology Center
<br>=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358
<br>
<br></blockquote></div></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@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/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a1135ef16a6858204f5e2f201--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 31 Mar 2014 12:26:25 -0400
Raw View
On 2014-03-30 01:46, Dmitry Akimov wrote:
> Well, if it will not be in the standard, then it is not worth trying,
> because people will ignore it, and it will be exactly the xkcd
> #927<https://xkcd.com/927/> (the
> 15 competing standards).
See Thiago's reply :-).
If you really care, I would take the boost approach; pick something that=20
already exists and work to get it adopted as "official" in some form.
Personally I like CMake for that purpose. I'm biased=C2=B9 of course :-), b=
ut=20
it solves all the problems Thiago listed and also provides=20
cross-platform utilities for creating and using package information.
(=C2=B9 Disclosure: I'm employed by Kitware, makers of CMake.)
> Defining the full-fledged package management system in the C++ standard
> would be an overkill, of course.
....until you care about a project with external dependencies. Which=20
you'll have to, if you want people to take your system seriously.
> I think it would be generally odd to make an argument like this: "We cann=
ot
> afford the solution covering all the possible use cases, so we shall
> continue covering none" (although people tend to make this sort of
> arguments *a lot*).
That may be true in general, but in this case we're not talking about=20
supporting corner cases, but typical use cases for non-toy projects.
Sure, you can trivially create a "standard" that can compile a 'Hello,=20
World!' program. If it can't compile *interesting* real world=20
applications though, what's the point?
--=20
Matthew
--=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/.
.