Re: [std-proposals] Standard project file

[Thiago Macieira]

Em qui 20 mar 2014, às 12:57:02, Dmitry Akimov escreveu:
> 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.

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

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

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

[Andrew Tomazos]

On Thu, Mar 20, 2014 at 8:57 PM, Dmitry Akimov <akimo...@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.

[Matthew Woehlke]

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

[Rui Pires]

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

--

--- 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-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

[David Krauss]

On 2014–03–29, at 6:55 PM, Dmitry Akimov <akimo...@gmail.com> wrote:

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 description of a component rather than a single code file?

Modules are supposed to tackle some definition of “component,” but it is sure 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 platform-specific information, such as what model UART the MCU includes, whether pointers 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 happen 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.

[Bjorn Reese]

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.

[Thiago Macieira]

Em sáb 29 mar 2014, às 03:55:25, Dmitry Akimov escreveu:
> > 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
> description of a component rather than a single code file?
>

> Could you provide a *rational* explanation?

Because the C++ Language standard defines, as the name says, the C++ Language.
If your project description is written in a different language, then it's not
the C++ Language.

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