Date: Tue, 13 Mar 2018 11:20:02 +0100
Hi
Just a few over-night thoughts...
I have been using and observing build systems and package management attempts over more than 30years. A few observations, most are regardless of programming language they stem from.
- young tools look sexy (for beginners), like young languages of toddler age
- but once used and extended they tend to become either too complex to use for beginners or too complicated to set up for real world projects
- there seem to be too many and often conflicting requirements, leading to
-- unusably complex tools building
-- high entry hurdles and
-- migration nightmares/high migration costs
-- reinvention of the wheel
-- DYI solutions
-- incompatible tools
-- utterly abominations
And as a corollary: it is a complex problem. There are too many dimensions, variations and uses for both package management and build systems (beyond just the C++ realm) that one can come up with a working satisfiable solution for many. Even with my experience i dare to list the potential dimensions.
If we want to simplify the entry hurdle for beginners, there is something we can work on, but we will never(?) be able to create something that will easily provide a cheap migration path for existing real world projects.
May be we lack the abstractions and means to effectively use them to describe what we want to get. Separate compilation units, multitude of binary formats, target platform-specific external restrictions, etc, just make the problem space so large it is very hard problem to solve satisfiable, even regardless migration from currently used solutions.
And even for languages where we might perceive that the problem is solved, does not mean a similar solution works for the C++ ecosystem.
So that was my pessimistic self. What can we do in an optimistic sense? Do i have ideas? Some. Are those ideas any good? i do not know.
Package management:
- isocpp.org could host and curate a central (open source) package index and provide a means for sharing libraries (CPAN, pypi,npm -like)
-- that already might be too much of a task to establish ( conan seems to try that, may be a starting point, but they already failed once with biicode)
Build tools:
- i am pessimistic here, but i believe in IDEs, where we support several and i think there might never be a suitable one stop/ one size fits all solution.
- we should at least try to ban the worst abominations and find abstractions to simplify specifications, i.e., a common compiler/linker calling convention. But again, commercial tools vendors ( compiler providers) might deliberately undermine any efforts here to retain customer lock-in (i am observing that!).
Sorry for falling back to pessimism. May be i should rest and brainstorm more positive ideas later.
Sent from Peter Sommerlad's iPad
+41 79 432 23 32
Just a few over-night thoughts...
I have been using and observing build systems and package management attempts over more than 30years. A few observations, most are regardless of programming language they stem from.
- young tools look sexy (for beginners), like young languages of toddler age
- but once used and extended they tend to become either too complex to use for beginners or too complicated to set up for real world projects
- there seem to be too many and often conflicting requirements, leading to
-- unusably complex tools building
-- high entry hurdles and
-- migration nightmares/high migration costs
-- reinvention of the wheel
-- DYI solutions
-- incompatible tools
-- utterly abominations
And as a corollary: it is a complex problem. There are too many dimensions, variations and uses for both package management and build systems (beyond just the C++ realm) that one can come up with a working satisfiable solution for many. Even with my experience i dare to list the potential dimensions.
If we want to simplify the entry hurdle for beginners, there is something we can work on, but we will never(?) be able to create something that will easily provide a cheap migration path for existing real world projects.
May be we lack the abstractions and means to effectively use them to describe what we want to get. Separate compilation units, multitude of binary formats, target platform-specific external restrictions, etc, just make the problem space so large it is very hard problem to solve satisfiable, even regardless migration from currently used solutions.
And even for languages where we might perceive that the problem is solved, does not mean a similar solution works for the C++ ecosystem.
So that was my pessimistic self. What can we do in an optimistic sense? Do i have ideas? Some. Are those ideas any good? i do not know.
Package management:
- isocpp.org could host and curate a central (open source) package index and provide a means for sharing libraries (CPAN, pypi,npm -like)
-- that already might be too much of a task to establish ( conan seems to try that, may be a starting point, but they already failed once with biicode)
Build tools:
- i am pessimistic here, but i believe in IDEs, where we support several and i think there might never be a suitable one stop/ one size fits all solution.
- we should at least try to ban the worst abominations and find abstractions to simplify specifications, i.e., a common compiler/linker calling convention. But again, commercial tools vendors ( compiler providers) might deliberately undermine any efforts here to retain customer lock-in (i am observing that!).
Sorry for falling back to pessimism. May be i should rest and brainstorm more positive ideas later.
Sent from Peter Sommerlad's iPad
+41 79 432 23 32
Received on 2018-03-13 11:20:09