Re: Announcement: Faber, a new build system based on bjam

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
not overly happy about the name - I think v20.0 or so of Faber, now into
its sixth century of existence, is just about good enough! But obviously
I don't have sole claim to the name

Long time list lurker, Jools (Faber)


On 10/11/2017 14:40, Stefan Seefeld via Boost wrote:

> Hello,
>
> about a year ago I started to experiment with a new Python frontend for
> Boost.Build. After many iterations of prototyping things are starting to
> fall into place, and the project stabilizes.
>
> I'm thus happy to announce the release of Faber version 0.2:
>
> code: https://github.com/stefanseefeld/faber
>
> docs: https://stefanseefeld.github.io/faber
>
> While Faber retains most of the features from Boost.Build, it is
> redesigned from the ground up. bjam is still used as scheduling engine,
> but everything else is written in Python. In particular, Jamfiles are
> replaced by fabscripts, which are essentially Python scripts. The
> project contains a range of examples to demonstrate various simple
> use-cases, from a simple "hello world" example to demos involving
> autoconf-style config checks, and unit testing.
>
> I have added build logic to Boost.Python to use Faber on Travis-CI as
> well as AppVeyor, which also is a good litmus test for Faber's capabilities.
>
> I'd be very interested in feedback as well as contributions. Perhaps it
> might become possible one day to integrate Faber with other efforts to
> add a Python frontend to Boost.Build.
>
> Regards,
>
> Stefan
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
The hard questions:

1. Can it cross-compile to iOS, android, OSX, linux and windows out of the box? (i.e. without me having to specify any magic command line options, environment variables or write any nasty scripts in some new syntax)

2. Can it identify, download and build dependencies automatically, using the correct toolset?

3. Will it create install scripts?

4. Will it package executables and libraries for later consumption?

5. will it build and deploy directly into docker?

These are the only questions I have regarding a build engine.

At the moment I use CMAKE with Hunter and Polly. Although it has a hideous syntax, this combination at least fulfils the basic requirements of a c++ cross-compiling build system in the modern age.

Currently nothing else does.




> On 10 Nov 2017, at 15:40, Stefan Seefeld via Boost <[hidden email]> wrote:
>
> Hello,
>
> about a year ago I started to experiment with a new Python frontend for
> Boost.Build. After many iterations of prototyping things are starting to
> fall into place, and the project stabilizes.
>
> I'm thus happy to announce the release of Faber version 0.2:
>
> code: https://github.com/stefanseefeld/faber
>
> docs: https://stefanseefeld.github.io/faber
>
> While Faber retains most of the features from Boost.Build, it is
> redesigned from the ground up. bjam is still used as scheduling engine,
> but everything else is written in Python. In particular, Jamfiles are
> replaced by fabscripts, which are essentially Python scripts. The
> project contains a range of examples to demonstrate various simple
> use-cases, from a simple "hello world" example to demos involving
> autoconf-style config checks, and unit testing.
>
> I have added build logic to Boost.Python to use Faber on Travis-CI as
> well as AppVeyor, which also is a good litmus test for Faber's capabilities.
>
> I'd be very interested in feedback as well as contributions. Perhaps it
> might become possible one day to integrate Faber with other efforts to
> add a Python frontend to Boost.Build.
>
> Regards,
>
> Stefan
>
> --
>
>      ...ich hab' noch einen Koffer in Berlin...
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
On 21.11.2017 15:02, Richard Hodges via Boost wrote:
> The hard questions:
>
> 1. Can it cross-compile to iOS, android, OSX, linux and windows out of the box? (i.e. without me having to specify any magic command line options, environment variables or write any nasty scripts in some new syntax)

Yes. (In principle, that is: So far I have focused on the design and
infrastructure. I know that it works, having (cross-)compiled with gcc,
clang, msvc, on Linux and Windows. There are still a lot of holes that
need to be filled by people who have access to the respective platforms
and tools.)

> 2. Can it identify, download and build dependencies automatically, using the correct toolset?

I'm not a fan of automatic downloads, though I don't see any reason why
such functionality couldn't be layered on top. All that is needed is a
convention for storing and handling the associated meta-information.

> 3. Will it create install scripts?

Likewise: adding packaging logic is (mostly) just a matter of adding
package meta-information as well as some tooling. The design fully
supports that. (It might be a good idea to add some sample package
generation logic to the next release, based on which other package
formats could be added later.)

> 4. Will it package executables and libraries for later consumption?

Same answer.
> 5. will it build and deploy directly into docker?

Can you describe the workflow you have in mind ? I'd expect the above
package building being the missing link. Everything beyond that seems
out of scope for a build tool.
> These are the only questions I have regarding a build engine.
>
> At the moment I use CMAKE with Hunter and Polly. Although it has a hideous syntax, this combination at least fulfils the basic requirements of a c++ cross-compiling build system in the modern age.

As I mentioned earlier, Faber should be feature-compatible with
Boost.Build. It's offering a different frontend language (Python), and
simplified logic (no "meta targets" etc.).
The main focus is easier use and extensibility than Boost.Build.
Everything from configuration, to testing and packaging is fully in
scope. But given that it can be used as a library, I'm sure that people
can come up with very different use-cases. and simply embed it into
other applications.


In case it isn't obvious: I very much welcome collaboration, so if you
want to contribute (be it more tools or even entirely new
functionality), I'd be happy to talk.

Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
Stephan wrote:

> In case it isn't obvious: I very much welcome collaboration, so if you
> want to contribute (be it more tools or even entirely new
> functionality), I'd be happy to talk.

Nothing would please me more than to be able to dump the horrific syntax of
cmake. I have often thought that python would be the obvious language for a
replacement. There was of course a similar tool called SCONS once, which is
python also. It seems to have fallen by the wayside.

What has prevented me making a start on a conversion is having recently
used node and npm. It seems that the rest of the world has converged on
javascript as the development script tool of choice.

I am strongly of the view that c++ needs a standard tool for build, IDE
project generation, toolset selection, dependency management, testing and
deployment. I find it deeply disturbing that one cannot simply write a
project that pulls in 3 or 4 libraries and then cross-compile it for any
target with one command.

It really should be as simple as:

build install --target=iOS10 --build_dir=[auto]
--install_dir=installs/iOS10 # an auto build dir would be named using a
hash of the target toolset, etc.
build install --target=[this-host] --build_dir=[auto]
--install_dir=/usr/local
build install --target=fedora25-docker --build_dir=[auto]
--install_dir=installs/dockers/fedora25

-j <cores_on_this_host> should be implied unless specified

wouldn't it get wider update/support though if it were in javascript and
available on npm? In this case at lease the dependency management of source
code is handled already?



On 21 November 2017 at 21:35, Stefan Seefeld via Boost <
[hidden email]> wrote:

> On 21.11.2017 15:02, Richard Hodges via Boost wrote:
> > The hard questions:
> >
> > 1. Can it cross-compile to iOS, android, OSX, linux and windows out of
> the box? (i.e. without me having to specify any magic command line options,
> environment variables or write any nasty scripts in some new syntax)
>
> Yes. (In principle, that is: So far I have focused on the design and
> infrastructure. I know that it works, having (cross-)compiled with gcc,
> clang, msvc, on Linux and Windows. There are still a lot of holes that
> need to be filled by people who have access to the respective platforms
> and tools.)
>
> > 2. Can it identify, download and build dependencies automatically, using
> the correct toolset?
>
> I'm not a fan of automatic downloads, though I don't see any reason why
> such functionality couldn't be layered on top. All that is needed is a
> convention for storing and handling the associated meta-information.
>
> > 3. Will it create install scripts?
>
> Likewise: adding packaging logic is (mostly) just a matter of adding
> package meta-information as well as some tooling. The design fully
> supports that. (It might be a good idea to add some sample package
> generation logic to the next release, based on which other package
> formats could be added later.)
>
> > 4. Will it package executables and libraries for later consumption?
>
> Same answer.
> > 5. will it build and deploy directly into docker?
>
> Can you describe the workflow you have in mind ? I'd expect the above
> package building being the missing link. Everything beyond that seems
> out of scope for a build tool.
> > These are the only questions I have regarding a build engine.
> >
> > At the moment I use CMAKE with Hunter and Polly. Although it has a
> hideous syntax, this combination at least fulfils the basic requirements of
> a c++ cross-compiling build system in the modern age.
>
> As I mentioned earlier, Faber should be feature-compatible with
> Boost.Build. It's offering a different frontend language (Python), and
> simplified logic (no "meta targets" etc.).
> The main focus is easier use and extensibility than Boost.Build.
> Everything from configuration, to testing and packaging is fully in
> scope. But given that it can be used as a library, I'm sure that people
> can come up with very different use-cases. and simply embed it into
> other applications.
>
>
> In case it isn't obvious: I very much welcome collaboration, so if you
> want to contribute (be it more tools or even entirely new
> functionality), I'd be happy to talk.
>
> Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
Hi,

this is an answer to Richards mail, but I am mostly addressing Stephan.

> On 22. Nov 2017, at 09:00, Richard Hodges via Boost <[hidden email]> wrote:
>
> Stephan wrote:
>
>> In case it isn't obvious: I very much welcome collaboration, so if you
>> want to contribute (be it more tools or even entirely new
>> functionality), I'd be happy to talk.
>
> Nothing would please me more than to be able to dump the horrific syntax of
> cmake. I have often thought that python would be the obvious language for a
> replacement. There was of course a similar tool called SCONS once, which is
> python also. It seems to have fallen by the wayside.


I am not a big fan of CMake and I do like Python very much, but the success of CMake shows me once again that people have surprising needs they are usually not concerned about how powerful the tool is for the technical expert. Mostly it is about making simple things simple and saving time for the average guy.

Here is my list why I believe CMake is so popular (ordered by perceived priority):
1) it is a high-level language for describing build trees, it allows me to ignore much of the technical low-level stuff, like how to call the compiler with the right options
2) the commands have nice long names which makes CMake build scripts almost self-documenting
3) it ships with a maintained collection of scripts to configure and include external libraries
4) there is a company behind it which continuously adapts cmake to its user base and advertises its use
5) the documentation is ok
6) it is comparably fast (Scons was rejected because it is slow, AFAIK), especially when you use the Ninja backend
7) it has a ncurses-based configuration interface
8) it produces pretty output

Since cmake has already an impressive following, this adds the most important item on the top of the list:
0) people already know the tool and don't have to learn it

Boost.Build does not offer points 0-4 and 7 and neither does Faber, it seems. The Hello World example in the Faber docs reminds me a lot of Makefiles, because of the $(<) and $(>) syntax.
# define some actions
compile = action('c++.compile', 'c++ -c -o $(<) $(>)')
link = action('c++.link', 'c++ -o $(<) $(>)')

# bind artefacts to sources using the above recipes
obj = rule(compile, 'hello.o', 'hello.cpp')
bin = rule(link, 'hello', obj)
test = rule(action('run_test', './$(>)'), 'test', bin, attrs=notfile|always)

default = bin
This looks rather mathematical and abstract. I appreciate math, but many people don't. The syntax is very terse, which I think is not good. For build scripts, I think that Cmake has a point with its long and descriptive names. I touch a build script only very rarely. If I touch it very rarely, I want it to be very easy to read, because I forgot all the little details of how it works after a few months. I learned CMake basically by looking at build scripts from other people, not by studying a documentation from ground up. This is incredibly useful, nobody likes to study manuals.

We had this discussion about the pros and cons of CMake a while ago, and it seems that nobody loves it, but it still seems like a useful compromise for many people. I don't see how Faber can compete with this, and I would prefer if we move Boost to CMake.

Best regards,
Hans

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
On Wed, Nov 22, 2017 at 5:12 AM, Hans Dembinski via Boost <
[hidden email]> wrote:

> Hi,
>
> this is an answer to Richards mail, but I am mostly addressing Stephan.
>
> > On 22. Nov 2017, at 09:00, Richard Hodges via Boost <
> [hidden email]> wrote:
> >
> > Stephan wrote:
> >
> >> In case it isn't obvious: I very much welcome collaboration, so if you
> >> want to contribute (be it more tools or even entirely new
> >> functionality), I'd be happy to talk.
> >
> > Nothing would please me more than to be able to dump the horrific syntax
> of
> > cmake. I have often thought that python would be the obvious language
> for a
> > replacement. There was of course a similar tool called SCONS once, which
> is
> > python also. It seems to have fallen by the wayside.
>
>
> I am not a big fan of CMake and I do like Python very much, but the
> success of CMake shows me once again that people have surprising needs they
> are usually not concerned about how powerful the tool is for the technical
> expert. Mostly it is about making simple things simple and saving time for
> the average guy.
>
> Here is my list why I believe CMake is so popular (ordered by perceived
> priority):
> 1) it is a high-level language for describing build trees, it allows me to
> ignore much of the technical low-level stuff, like how to call the compiler
> with the right options
> 2) the commands have nice long names which makes CMake build scripts
> almost self-documenting
> 3) it ships with a maintained collection of scripts to configure and
> include external libraries
> 4) there is a company behind it which continuously adapts cmake to its
> user base and advertises its use
> 5) the documentation is ok
> 6) it is comparably fast (Scons was rejected because it is slow, AFAIK),
> especially when you use the Ninja backend
> 7) it has a ncurses-based configuration interface
> 8) it produces pretty output
>
> Since cmake has already an impressive following, this adds the most
> important item on the top of the list:
> 0) people already know the tool and don't have to learn it
>
> Boost.Build does not offer points 0-4 and 7 and neither does Faber, it
> seems. The Hello World example in the Faber docs reminds me a lot of
> Makefiles, because of the $(<) and $(>) syntax.
> # define some actions
> compile = action('c++.compile', 'c++ -c -o $(<) $(>)')
> link = action('c++.link', 'c++ -o $(<) $(>)')
>
> # bind artefacts to sources using the above recipes
> obj = rule(compile, 'hello.o', 'hello.cpp')
> bin = rule(link, 'hello', obj)
> test = rule(action('run_test', './$(>)'), 'test', bin,
> attrs=notfile|always)
>
> default = bin
> This looks rather mathematical and abstract. I appreciate math, but many
> people don't. The syntax is very terse, which I think is not good. For
> build scripts, I think that Cmake has a point with its long and descriptive
> names. I touch a build script only very rarely. If I touch it very rarely,
> I want it to be very easy to read, because I forgot all the little details
> of how it works after a few months. I learned CMake basically by looking at
> build scripts from other people, not by studying a documentation from
> ground up. This is incredibly useful, nobody likes to study manuals.
>
> We had this discussion about the pros and cons of CMake a while ago, and
> it seems that nobody loves it, but it still seems like a useful compromise
> for many people. I don't see how Faber can compete with this, and I would
> prefer if we move Boost to CMake.
>
> Best regards,
> Hans
>
>
I thought the decision was already made to move to CMake based on an
announcement that was made a couple months ago?  It's true that sometimes
CMake is lacking, for example it has no built-in support on Windows to
select a static versus dynamic runtime (one can set the compile flags at
generation time however), nor does it do a good job at packaging up PDB
files when building install targets for build types that include debug
info.  That said, I have used it for a long time now (over 10 years) and
find it to be the most complete and easiest to understand/use
cross-platform build system.  Regarding package management, the conan C/C++
package manager team has a project for cmake integration.  Hans summarized
the good points nicely above, but missed a couple key points I find useful
- CMake produces parallel-build-capable build scripts, and it can generate
both Eclipse and Visual Studio projects.  Many open-source projects already
use CMake (which is not limited to just building C/C++ by the way), and
given the active and robust ecosystem that exists around it, CMake will be
my tool of choice for some time to come.

- Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 22.11.2017 05:12, Hans Dembinski via Boost wrote:
> Hi,
>
> this is an answer to Richards mail, but I am mostly addressing Stephan.

Let me reply to both your mails here...


>
>> On 22. Nov 2017, at 09:00, Richard Hodges via Boost <[hidden email]> wrote:
>>
>> Stephan wrote:
>>
>>> In case it isn't obvious: I very much welcome collaboration, so if you
>>> want to contribute (be it more tools or even entirely new
>>> functionality), I'd be happy to talk.
>> Nothing would please me more than to be able to dump the horrific syntax of
>> cmake. I have often thought that python would be the obvious language for a
>> replacement. There was of course a similar tool called SCONS once, which is
>> python also. It seems to have fallen by the wayside.

Not at all. SCons is well alive (and I have contributed to it in the
past, even mentored a GSoC student for it).
There are fundamental differences, though, and (as you mention it) I
think its interface is quite unpythonic, unfortunately, despite the
superficial fact that it uses Python for its SConscripts.

>
> I am not a big fan of CMake and I do like Python very much, but the success of CMake shows me once again that people have surprising needs they are usually not concerned about how powerful the tool is for the technical expert. Mostly it is about making simple things simple and saving time for the average guy.
Yes. But despite its popularity, I disagree with CMake's approach on a
very fundamental level (it being a build system generator, rather than a
build system), as it makes things oh so much more complex. Everything
works well until it doesn't, at which point all hell breaks loose.
That's very typical for macro-based languages (think latex, m4). And it
had to reinvent its own language, in a rather ad-hoc manner (i.e.
started with a simple declarative syntax, but then had to expand on that
to cover other use-cases. "Now you have two problems." comes to mind (if
I may paraphrase).

>
> Here is my list why I believe CMake is so popular (ordered by perceived priority):
> 1) it is a high-level language for describing build trees, it allows me to ignore much of the technical low-level stuff, like how to call the compiler with the right options
> 2) the commands have nice long names which makes CMake build scripts almost self-documenting
> 3) it ships with a maintained collection of scripts to configure and include external libraries
> 4) there is a company behind it which continuously adapts cmake to its user base and advertises its use
> 5) the documentation is ok
> 6) it is comparably fast (Scons was rejected because it is slow, AFAIK), especially when you use the Ninja backend
> 7) it has a ncurses-based configuration interface
> 8) it produces pretty output
>
> Since cmake has already an impressive following, this adds the most important item on the top of the list:
> 0) people already know the tool and don't have to learn it
>
> Boost.Build does not offer points 0-4 and 7

I'd contest that. Boost.Build does hide most details about tool
internals (how to invoke the compiler, say), until you need to plug in
your own tools.


> and neither does Faber, it seems. The Hello World example in the Faber docs reminds me a lot of Makefiles, because of the $(<) and $(>) syntax.

Yes, intentionally so. (Well, also because that's what bjam uses, and I
didn't see any reason to change that.) A scheduling tool that invokes
external tools to update artefacts needs some kind of DSL, and I think
constructs such as $(>) seem rather intuitive. The fact that `make` (as
the de-facto standard in UNIX land) uses the same language can only help.


> # define some actions
> compile = action('c++.compile', 'c++ -c -o $(<) $(>)')
> link = action('c++.link', 'c++ -o $(<) $(>)')
>
> # bind artefacts to sources using the above recipes
> obj = rule(compile, 'hello.o', 'hello.cpp')
> bin = rule(link, 'hello', obj)
> test = rule(action('run_test', './$(>)'), 'test', bin, attrs=notfile|always)
>
> default = bin
> This looks rather mathematical and abstract. I appreciate math, but many people don't. The syntax is very terse, which I think is not good. For build scripts, I think that Cmake has a point with its long and descriptive names. I touch a build script only very rarely. If I touch it very rarely, I want it to be very easy to read, because I forgot all the little details of how it works after a few months. I learned CMake basically by looking at build scripts from other people, not by studying a documentation from ground up. This is incredibly useful, nobody likes to study manuals.

Thanks for your feedback. I may rethink how I document Faber. As a
developer, I typically much prefer a bottom-up approach, starting with
the lowest details, then adding layer upon layer of abstraction. So what
you are looking for is likely persent in a higher layer. Have a look at
one of the other examples:

from faber.artefacts.binary import binary

greet = module('greet')

hello = binary('hello', ['hello.cpp', greet.greet])

rule(action('test', '$(>)'), 'test', hello, attrs=notfile|always)

default = hello

(from
https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript),
which uses higher-level artefacts (`binary`, `library`) and doesn't
require the user to define his own actions to build.



>
> We had this discussion about the pros and cons of CMake a while ago, and it seems that nobody loves it, but it still seems like a useful compromise for many people. I don't see how Faber can compete with this, and I would prefer if we move Boost to CMake.

As much as I'd love for people to adopt Faber, I'm not proposing Boost
(as a whole) to move to any tool in particular. I have expressed this
view in the past, and I don't want to distract this thread (about Faber)
with discussions about Boost's strategy moving forward.

The reason I propose Faber here is as a fork (or, in a way, a new
frontend) of Boost.Build, so people who have been struggling with
Boost.Build in the past may want to look at this as a possible alternative.


Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
On Wed, Nov 22, 2017 at 2:43 PM, Stefan Seefeld via Boost <
[hidden email]> wrote:

> On 22.11.2017 05:12, Hans Dembinski via Boost wrote:
> > and neither does Faber, it seems. The Hello World example in the Faber
> docs reminds me a lot of Makefiles, because of the $(<) and $(>) syntax.
>
> Yes, intentionally so. (Well, also because that's what bjam uses, and I
> didn't see any reason to change that.) A scheduling tool that invokes
> external tools to update artefacts needs some kind of DSL, and I think
> constructs such as $(>) seem rather intuitive. The fact that `make` (as
> the de-facto standard in UNIX land) uses the same language can only help.
>
> > # define some actions
> > compile = action('c++.compile', 'c++ -c -o $(<) $(>)')
>

Like Hans, I've also never been fond of $(<) or $(>).
You invoke Make heritage here for the terseness,
while previously you justified Boost.Build rewrite into Faber on clarity
grounds.
You can't have it both ways Stefan ;)

From a Shell perspective, $(<) evokes input to me, and $(>) output, the
reverse
of what they likely mean above, given the -o. Playing devil's advocate I
guess.

I did have a look at the doc when you announced it, and was quickly turned
of by the syntax, to be honest.

My $0.02. --DD

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
On 22.11.2017 09:33, Dominique Devienne via Boost wrote:

> On Wed, Nov 22, 2017 at 2:43 PM, Stefan Seefeld via Boost <
> [hidden email]> wrote:
>
>> On 22.11.2017 05:12, Hans Dembinski via Boost wrote:
>>> and neither does Faber, it seems. The Hello World example in the Faber
>> docs reminds me a lot of Makefiles, because of the $(<) and $(>) syntax.
>>
>> Yes, intentionally so. (Well, also because that's what bjam uses, and I
>> didn't see any reason to change that.) A scheduling tool that invokes
>> external tools to update artefacts needs some kind of DSL, and I think
>> constructs such as $(>) seem rather intuitive. The fact that `make` (as
>> the de-facto standard in UNIX land) uses the same language can only help.
>>
>>> # define some actions
>>> compile = action('c++.compile', 'c++ -c -o $(<) $(>)')
> Like Hans, I've also never been fond of $(<) or $(>).
> You invoke Make heritage here for the terseness,
> while previously you justified Boost.Build rewrite into Faber on clarity
> grounds.
> You can't have it both ways Stefan ;)
>
> From a Shell perspective, $(<) evokes input to me, and $(>) output, the
> reverse
> of what they likely mean above, given the -o. Playing devil's advocate I
> guess.

From the C++ community I had expected a different reaction. Or perhaps
the above should be spelled '<<' and '>>' ? :-)
But more seriously, I had hoped the discussion to be more focussed on
general design than on spelling. I expect the majority of users will
never see (nor care about) how actions are defined, as they will merely
use pre-defined built-tin actions such as `c++.compile`,
`fileutils.copy`, or `python.run`.


Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Nov 22, 2017 at 3:00 AM, Richard Hodges via Boost <
[hidden email]> wrote:



> I am strongly of the view that c++ needs a standard tool for build, IDE
> project generation, toolset selection, dependency management, testing and
> deployment. I find it deeply disturbing that one cannot simply write a
> project that pulls in 3 or 4 libraries and then cross-compile it for any
> target with one command.
>
>
FWIW, the C++ standards committee is in the process of setting up a new
Study Group for Tooling. Titus Winters will be the chair. I suspect it will
initially focus on tooling to support P0684 *C++ Stability, Velocity, and
Deployment Plans *(See https://wg21.link/p0684), but it is a sign of
increased interest in the whole C++ ecosystem.

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> On 22. Nov 2017, at 15:42, Stefan Seefeld via Boost <[hidden email]> wrote:
>>>> # define some actions
>>>> compile = action('c++.compile', 'c++ -c -o $(<) $(>)')
>> Like Hans, I've also never been fond of $(<) or $(>).
>> You invoke Make heritage here for the terseness,
>> while previously you justified Boost.Build rewrite into Faber on clarity
>> grounds.
>> You can't have it both ways Stefan ;)
>>
>> From a Shell perspective, $(<) evokes input to me, and $(>) output, the
>> reverse
>> of what they likely mean above, given the -o. Playing devil's advocate I
>> guess.
>
> From the C++ community I had expected a different reaction. Or perhaps
> the above should be spelled '<<' and '>>' ? :-)

You could maybe use $(in) and $(out). There is no ambiguity then and there are not many more characters to type either.

> But more seriously, I had hoped the discussion to be more focussed on
> general design than on spelling.

I value code readability (which includes avoiding ambiguity) a lot, as you can see in the other thread concerning the histogram library. It is not just bike-shedding, if there is an alternative that is less ambiguous/easier to read.

> I expect the majority of users will
> never see (nor care about) how actions are defined, as they will merely
> use pre-defined built-tin actions such as `c++.compile`,
> `fileutils.copy`, or `python.run`.

I don't know about that. And also, why not make life more pleasant for the power user as well, who needs custom actions? Ideally, a software is appealing to both the casual and the power user.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> On 22. Nov 2017, at 14:43, Stefan Seefeld via Boost <[hidden email]> wrote:
>>> On 22. Nov 2017, at 09:00, Richard Hodges via Boost <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> Stephan wrote:
>>>
>>>> In case it isn't obvious: I very much welcome collaboration, so if you
>>>> want to contribute (be it more tools or even entirely new
>>>> functionality), I'd be happy to talk.
>>> Nothing would please me more than to be able to dump the horrific syntax of
>>> cmake. I have often thought that python would be the obvious language for a
>>> replacement. There was of course a similar tool called SCONS once, which is
>>> python also. It seems to have fallen by the wayside.
>
> Not at all. SCons is well alive (and I have contributed to it in the
> past, even mentored a GSoC student for it).
> There are fundamental differences, though, and (as you mention it) I
> think its interface is quite unpythonic, unfortunately, despite the
> superficial fact that it uses Python for its SConscripts.

I was referring to the fact that big OS projects moved away from SCons to CMake, notably KDE. This article nicely explains some issues with SCons.
https://lwn.net/Articles/188693/

I think that using an established scripting language to write build scripts is a great idea. I like that about Faber and about Scons, and I think it is bad that CMake established yet another scripting language, effectively.

The annoying thing about SConscripts is that it looks like Python, but the behaviour is different, since the order of statements is not maintained. It looks like Python, but it behaves like a Makefile, where only the dependencies of the statements matter and not the order in the code. This is inconsistent.

>> I am not a big fan of CMake and I do like Python very much, but the success of CMake shows me once again that people have surprising needs they are usually not concerned about how powerful the tool is for the technical expert. Mostly it is about making simple things simple and saving time for the average guy.
> Yes. But despite its popularity, I disagree with CMake's approach on a
> very fundamental level (it being a build system generator, rather than a
> build system), as it makes things oh so much more complex. Everything
> works well until it doesn't, at which point all hell breaks loose.
> That's very typical for macro-based languages (think latex, m4). And it
> had to reinvent its own language, in a rather ad-hoc manner (i.e.
> started with a simple declarative syntax, but then had to expand on that
> to cover other use-cases. "Now you have two problems." comes to mind (if
> I may paraphrase).

I agree with you on all points, like most people would. Like I said, I am not in love with CMake either.

>> Here is my list why I believe CMake is so popular (ordered by perceived priority):
>> 1) it is a high-level language for describing build trees, it allows me to ignore much of the technical low-level stuff, like how to call the compiler with the right options
>> 2) the commands have nice long names which makes CMake build scripts almost self-documenting
>> 3) it ships with a maintained collection of scripts to configure and include external libraries
>> 4) there is a company behind it which continuously adapts cmake to its user base and advertises its use
>> 5) the documentation is ok
>> 6) it is comparably fast (Scons was rejected because it is slow, AFAIK), especially when you use the Ninja backend
>> 7) it has a ncurses-based configuration interface
>> 8) it produces pretty output
>>
>> Since cmake has already an impressive following, this adds the most important item on the top of the list:
>> 0) people already know the tool and don't have to learn it
>>
>> Boost.Build does not offer points 0-4 and 7
>
> I'd contest that. Boost.Build does hide most details about tool
> internals (how to invoke the compiler, say), until you need to plug in
> your own tools.

Ok, you are right.

>> # define some actions
>> compile = action('c++.compile', 'c++ -c -o $(<) $(>)')
>> link = action('c++.link', 'c++ -o $(<) $(>)')
>>
>> # bind artefacts to sources using the above recipes
>> obj = rule(compile, 'hello.o', 'hello.cpp')
>> bin = rule(link, 'hello', obj)
>> test = rule(action('run_test', './$(>)'), 'test', bin, attrs=notfile|always)
>>
>> default = bin
>> This looks rather mathematical and abstract. I appreciate math, but many people don't. The syntax is very terse, which I think is not good. For build scripts, I think that Cmake has a point with its long and descriptive names. I touch a build script only very rarely. If I touch it very rarely, I want it to be very easy to read, because I forgot all the little details of how it works after a few months. I learned CMake basically by looking at build scripts from other people, not by studying a documentation from ground up. This is incredibly useful, nobody likes to study manuals.
>
> Thanks for your feedback. I may rethink how I document Faber. As a
> developer, I typically much prefer a bottom-up approach, starting with
> the lowest details, then adding layer upon layer of abstraction. So what
> you are looking for is likely persent in a higher layer. Have a look at
> one of the other examples:

Yes, I think providing high-level examples first is better to draw people in.

> from faber.artefacts.binary import binary
>
> greet = module('greet')
>
> hello = binary('hello', ['hello.cpp', greet.greet])
>
> rule(action('test', '$(>)'), 'test', hello, attrs=notfile|always)
>
> default = hello
>
> (from
> https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript <https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript>),
> which uses higher-level artefacts (`binary`, `library`) and doesn't
> require the user to define his own actions to build.

This example remains cryptic.

from faber.artefacts...: artefacts? The term "artefact" is very general and non-descriptive. The first definition provided by Google is essentially "human-made thing".

Then, I have to type many redundant things here. Note, the many occurrences of greet in these two lines

greet = module('greet')
hello = binary('hello', ['hello.cpp', greet.greet])

It seems like hello is a binary which depends on 'hello.cpp' and the module greet. Why the latter?

The rule to make a test is very cryptic. The action takes several positional arguments, and I can only guess what each positional argument does. I am also critical about this in bjam. By using a syntax that uses a lot of positional arguments, you need to read the documentation to figure out what is going on. If you are lucky, the author provided comments for each positional argument, but then one might as well use keywords which are self-documenting. This is what CMake does well, IMHO.

Best regards,
Hans

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
On 29.11.2017 07:59, Hans Dembinski wrote:

>
>> from faber.artefacts.binary import binary
>>
>> greet = module('greet')
>>
>> hello = binary('hello', ['hello.cpp', greet.greet])
>>
>> rule(action('test', '$(>)'), 'test', hello, attrs=notfile|always)
>>
>> default = hello
>>
>> (from
>> https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript),
>> which uses higher-level artefacts (`binary`, `library`) and doesn't
>> require the user to define his own actions to build.
>
> This example remains cryptic.
>
> from faber.artefacts...: artefacts? The term "artefact" is very
> general and non-descriptive. The first definition provided by Google
> is essentially "human-made thing".

Right, it's what "faber" generates (using the same stem even).

>
> Then, I have to type many redundant things here. Note, the many
> occurrences of greet in these two lines
>
> greet = module('greet')
> hello = binary('hello', ['hello.cpp', greet.greet])
>
> It seems like hello is a binary which depends on 'hello.cpp' and the
> module greet. Why the latter?

"hello" is a binary built from a "hello.cpp" source file and a "greet"
library provided from another ("greet") module (thus using Pythonic
syntax, we refer to the latter as "greet.greet").
If the library would have been built by the same module, the above would
simply be

greet = library('greet', 'greet.cpp')
hello = binary('hello', ['hello.cpp', greet])

as is in fact done in this example:
https://github.com/stefanseefeld/faber/blob/develop/examples/implicit_rules/fabscript

>
> The rule to make a test is very cryptic. The action takes several
> positional arguments, and I can only guess what each positional
> argument does.

rules take at least two (positional) arguments (an action and a name for
the target artefact). All other arguments have default values, and thus
*may* be given as keyword arguments or as positional arguments,
depending on your preference. (But given that a "source" argument is
still very common, I just chose to not spell it out as "source=hello"
for compactness.) As a fabscript author you are of course free to name
all your rule arguments, if that helps readability. I not inventing
anything here, but rather take the most natural approach possible
following Python language rules and idioms.

> I am also critical about this in bjam. By using a syntax that uses a
> lot of positional arguments, you need to read the documentation to
> figure out what is going on.

Again, Python allows you to name all arguments. This is up to the
caller, not the API designer. As far as the API is concerned, rules have
two mandatory arguments, so it wouldn't make sense to make them keyword
arguments.

But if you prefer some help in drafting your fabscript logic, there are
good tools to help interactively editing Python code, including code
completion etc.
That's the beauty of using Python: we can tap into a fabulous ecosystem
of tools and modules, including ipython, jupyter, spyder, etc., etc.
In any case, nothing is cast in stone just yet. One reason I decided to
publish Faber now was to gather feedback and interest in collaboration,
and I expect lots of things to change as we collectively improve upon
what's already there.


> If you are lucky, the author provided comments for each positional
> argument, but then one might as well use keywords which are
> self-documenting. This is what CMake does well, IMHO.



Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list

> On 29. Nov 2017, at 14:31, Stefan Seefeld <[hidden email]> wrote:
>
> On 29.11.2017 07:59, Hans Dembinski wrote:
>>
>>> from faber.artefacts.binary import binary
>>>
>>> greet = module('greet')
>>>
>>> hello = binary('hello', ['hello.cpp', greet.greet])
>>>
>>> rule(action('test', '$(>)'), 'test', hello, attrs=notfile|always)
>>>
>>> default = hello
>>>
>>> (from
>>> https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript <https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript>),
>>> which uses higher-level artefacts (`binary`, `library`) and doesn't
>>> require the user to define his own actions to build.
>>
>> This example remains cryptic.
>>
>> from faber.artefacts...: artefacts? The term "artefact" is very general and non-descriptive. The first definition provided by Google is essentially "human-made thing".
>
> Right, it's what "faber" generates (using the same stem even).

:) Fair enough, but it is still not very descriptive. Why use an uncommon latin word if you could use a common word from day-to-day language? The purpose of language is to transmit information, so it is usually a good idea to use common words that leave no room for ambiguity.

Ironically, the other meaning of "artefact" is "any error in the *perception or representation of any information*, introduced by the involved equipment or technique(s)" [Wikipedia]

>> Then, I have to type many redundant things here. Note, the many occurrences of greet in these two lines
>>
>> greet = module('greet')
>> hello = binary('hello', ['hello.cpp', greet.greet])
>>
>> It seems like hello is a binary which depends on 'hello.cpp' and the module greet. Why the latter?
>
> "hello" is a binary built from a "hello.cpp" source file and a "greet" library provided from another ("greet") module (thus using Pythonic syntax, we refer to the latter as "greet.greet").
> If the library would have been built by the same module, the above would simply be
>
> greet = library('greet', 'greet.cpp')
> hello = binary('hello', ['hello.cpp', greet])
>
> as is in fact done in this example: https://github.com/stefanseefeld/faber/blob/develop/examples/implicit_rules/fabscript <https://github.com/stefanseefeld/faber/blob/develop/examples/implicit_rules/fabscript>

I think source code is allowed to be verbose, but it should not be redundant, especially if said redundancy could lead to mistakes. I suppose you run the fabscript through a special interpreter, not just the standard Python interpreter. If so, then you can use this shorthand syntax instead:

greet = library('greet.cpp')

That way, one cannot make a mistake like this

greet = library('great', 'greet.cpp')

To make the syntax very consistent (the Zen of Python says: "There should be one - preferably only one - obvious way to do it."), you could define all build items like library and binary in this way:

def binary(*inputs, attribute1=default1, attribute2=default2, …): ...

All positional arguments would always be inputs of any kind, like a source file or a library. If you always use positional arguments consistently like this, then my complaint about ambiguity is gone, because there is a clear rule which is easy to remember.

Attributes would be passed consistently via keywords. They have reasonable defaults that Faber picks for me. Like, if I want another file extension for a library than the default for the platform. For libraries, I could specify whether to build a static or shared one. Or if I really don't want to name the library "greet", I could pass the keyword name="great".

This declaration enforces the use of keywords for attributes, positional arguments are not allowed for attributes, which is a good for clarity.

>> The rule to make a test is very cryptic. The action takes several positional arguments, and I can only guess what each positional argument does.
>
> rules take at least two (positional) arguments (an action and a name for the target artefact). All other arguments have default values,     and thus *may* be given as keyword arguments or as positional arguments, depending on your preference. (But given that a "source" argument is still very common, I just chose to not spell it out as "source=hello" for compactness.) As a fabscript author you are of course free to name all your rule arguments, if that helps readability. I not inventing anything here, but rather take the most natural approach possible following Python language rules and idioms.
>
>> I am also critical about this in bjam. By using a syntax that uses a lot of positional arguments, you need to read the documentation to figure out what is going on.
>
> Again, Python allows you to name all arguments. This is up to the caller, not the API designer. As far as the API is concerned, rules have two mandatory arguments, so it wouldn't make sense to make them keyword arguments.

I hope I explained better above what I had in mind. I agree, of course, that writing things like source="bla" all the time is annoying and superfluous.

> But if you prefer some help in drafting your fabscript logic, there are good tools to help interactively editing Python code, including code completion etc.
> That's the beauty of using Python: we can tap into a fabulous ecosystem of tools and modules, including ipython, jupyter, spyder, etc., etc.

Agreed, that's why I am also in favour of using an established scripting language to describe a build tree. I am sorry that I am so critical, but we have some common ground. All this is meant in a constructive way.

Best regards,
Hans


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
This discussion will eventually lead to the realisation that a cross-platform builder tool requires separate concepts for (amongst others):

* source files
* libraries (dynamic and static)
* dependencies
* executables built for the target system
* executables built for the build host (i.e. intermediate build tools)
* scopes
* -D macro definitions
* abstractions of compiler options
* abstractions of build host fundamental operations (environment variables, file existence, file copying, file locks, spawning subprocesses etc)

… and so on.

To short-circuit the discussion I can offer the following observations:

* bjam, clever as it is, is basically a form of makefile. It will never be a build tool It’s therefore not useful to anyone but boost maintainers or single-target projects.

* makefiles are great for creating dependency graphs. They are suitable for the output or intermediate stages of a build tool. You build a makefile hierarchy from the build tool abstractions given a target toolset and options.

We already have Scons and CMake, which are both awful in their own way.

I really think that effort would be better spent retro fitting python (or javascript, or [insert well maintained scripting language here]) into cmake so that cmake becomes beautiful.

Either that, or recreate cmake in python (or javascript), but cleanly, using the combined knowledge of several years of evolution.

Why the cmake team chose to build their own godawful scripting language is a mystery to me. I suspect someone just wanted to write a DSL one day and it all got way out of hand (original poster, please take note!)

R





> On 30 Nov 2017, at 11:51, Hans Dembinski via Boost <[hidden email]> wrote:
>
>
>> On 29. Nov 2017, at 14:31, Stefan Seefeld <[hidden email]> wrote:
>>
>> On 29.11.2017 07:59, Hans Dembinski wrote:
>>>
>>>> from faber.artefacts.binary import binary
>>>>
>>>> greet = module('greet')
>>>>
>>>> hello = binary('hello', ['hello.cpp', greet.greet])
>>>>
>>>> rule(action('test', '$(>)'), 'test', hello, attrs=notfile|always)
>>>>
>>>> default = hello
>>>>
>>>> (from
>>>> https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript <https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript>),
>>>> which uses higher-level artefacts (`binary`, `library`) and doesn't
>>>> require the user to define his own actions to build.
>>>
>>> This example remains cryptic.
>>>
>>> from faber.artefacts...: artefacts? The term "artefact" is very general and non-descriptive. The first definition provided by Google is essentially "human-made thing".
>>
>> Right, it's what "faber" generates (using the same stem even).
>
> :) Fair enough, but it is still not very descriptive. Why use an uncommon latin word if you could use a common word from day-to-day language? The purpose of language is to transmit information, so it is usually a good idea to use common words that leave no room for ambiguity.
>
> Ironically, the other meaning of "artefact" is "any error in the *perception or representation of any information*, introduced by the involved equipment or technique(s)" [Wikipedia]
>
>>> Then, I have to type many redundant things here. Note, the many occurrences of greet in these two lines
>>>
>>> greet = module('greet')
>>> hello = binary('hello', ['hello.cpp', greet.greet])
>>>
>>> It seems like hello is a binary which depends on 'hello.cpp' and the module greet. Why the latter?
>>
>> "hello" is a binary built from a "hello.cpp" source file and a "greet" library provided from another ("greet") module (thus using Pythonic syntax, we refer to the latter as "greet.greet").
>> If the library would have been built by the same module, the above would simply be
>>
>> greet = library('greet', 'greet.cpp')
>> hello = binary('hello', ['hello.cpp', greet])
>>
>> as is in fact done in this example: https://github.com/stefanseefeld/faber/blob/develop/examples/implicit_rules/fabscript <https://github.com/stefanseefeld/faber/blob/develop/examples/implicit_rules/fabscript>
>
> I think source code is allowed to be verbose, but it should not be redundant, especially if said redundancy could lead to mistakes. I suppose you run the fabscript through a special interpreter, not just the standard Python interpreter. If so, then you can use this shorthand syntax instead:
>
> greet = library('greet.cpp')
>
> That way, one cannot make a mistake like this
>
> greet = library('great', 'greet.cpp')
>
> To make the syntax very consistent (the Zen of Python says: "There should be one - preferably only one - obvious way to do it."), you could define all build items like library and binary in this way:
>
> def binary(*inputs, attribute1=default1, attribute2=default2, …): ...
>
> All positional arguments would always be inputs of any kind, like a source file or a library. If you always use positional arguments consistently like this, then my complaint about ambiguity is gone, because there is a clear rule which is easy to remember.
>
> Attributes would be passed consistently via keywords. They have reasonable defaults that Faber picks for me. Like, if I want another file extension for a library than the default for the platform. For libraries, I could specify whether to build a static or shared one. Or if I really don't want to name the library "greet", I could pass the keyword name="great".
>
> This declaration enforces the use of keywords for attributes, positional arguments are not allowed for attributes, which is a good for clarity.
>
>>> The rule to make a test is very cryptic. The action takes several positional arguments, and I can only guess what each positional argument does.
>>
>> rules take at least two (positional) arguments (an action and a name for the target artefact). All other arguments have default values,     and thus *may* be given as keyword arguments or as positional arguments, depending on your preference. (But given that a "source" argument is still very common, I just chose to not spell it out as "source=hello" for compactness.) As a fabscript author you are of course free to name all your rule arguments, if that helps readability. I not inventing anything here, but rather take the most natural approach possible following Python language rules and idioms.
>>
>>> I am also critical about this in bjam. By using a syntax that uses a lot of positional arguments, you need to read the documentation to figure out what is going on.
>>
>> Again, Python allows you to name all arguments. This is up to the caller, not the API designer. As far as the API is concerned, rules have two mandatory arguments, so it wouldn't make sense to make them keyword arguments.
>
> I hope I explained better above what I had in mind. I agree, of course, that writing things like source="bla" all the time is annoying and superfluous.
>
>> But if you prefer some help in drafting your fabscript logic, there are good tools to help interactively editing Python code, including code completion etc.
>> That's the beauty of using Python: we can tap into a fabulous ecosystem of tools and modules, including ipython, jupyter, spyder, etc., etc.
>
> Agreed, that's why I am also in favour of using an established scripting language to describe a build tree. I am sorry that I am so critical, but we have some common ground. All this is meant in a constructive way.
>
> Best regards,
> Hans
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
On 30.11.2017 06:57, Richard Hodges via Boost wrote:

> This discussion will eventually lead to the realisation that a cross-platform builder tool requires separate concepts for (amongst others):
>
> * source files
> * libraries (dynamic and static)
> * dependencies
> * executables built for the target system
> * executables built for the build host (i.e. intermediate build tools)
> * scopes
> * -D macro definitions
> * abstractions of compiler options
> * abstractions of build host fundamental operations (environment variables, file existence, file copying, file locks, spawning subprocesses etc)
>
> … and so on.

What's your point ? I think everyone understands that.

> To short-circuit the discussion I can offer the following observations:
>
> * bjam, clever as it is, is basically a form of makefile. It will never be a build tool It’s therefore not useful to anyone but boost maintainers or single-target projects.

That sounds like a rather unsubstantial rant. Can you elaborate on what
you mean by that ?

>
> * makefiles are great for creating dependency graphs. They are suitable for the output or intermediate stages of a build tool. You build a makefile hierarchy from the build tool abstractions given a target toolset and options.
>
> We already have Scons and CMake, which are both awful in their own way.
>
> I really think that effort would be better spent retro fitting python (or javascript, or [insert well maintained scripting language here]) into cmake so that cmake becomes beautiful.
>
> Either that, or recreate cmake in python (or javascript), but cleanly, using the combined knowledge of several years of evolution.
>
> Why the cmake team chose to build their own godawful scripting language is a mystery to me. I suspect someone just wanted to write a DSL one day and it all got way out of hand (original poster, please take note!)
>
> R

Sorry, but I still don't understand what you are trying to say. (I don't
agree that CMake would be great if it used a better language. I think it
is flawed on multiple levels. The fact that it wants to be a build
system generator rather than a build system probably being the central
issue.)

But, to get back to the original topic (which was the Faber
announcement): have you looked at it (either the docs or the code) ? Can
you substantiate your claim that it doesn't meet the points in your
shopping list above ?

Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Hans Dembinski via Boost
> Sent: 30 November 2017 10:52
> To: Stefan Seefeld
> Cc: Hans Dembinski; [hidden email]
> Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
>
>
> > On 29. Nov 2017, at 14:31, Stefan Seefeld <[hidden email]> wrote:
> >
> > On 29.11.2017 07:59, Hans Dembinski wrote:
> >>
> >>> from faber.artefacts.binary import binary
> >>>
> >>> greet = module('greet')
> >>>
> >>> hello = binary('hello', ['hello.cpp', greet.greet])
> >>>
> >>> rule(action('test', '$(>)'), 'test', hello, attrs=notfile|always)
> >>>
> >>> default = hello
> >>>
> >>> (from
> >>> https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript
> <https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript>),
> >>> which uses higher-level artefacts (`binary`, `library`) and doesn't
> >>> require the user to define his own actions to build.
> >>
> >> This example remains cryptic.
> >>
> >> from faber.artefacts...: artefacts? The term "artefact" is very general and non-descriptive. The first definition provided by
> Google is essentially "human-made thing".
> >
> > Right, it's what "faber" generates (using the same stem even).
>
> :) Fair enough, but it is still not very descriptive. Why use an uncommon latin word if you could use a common word from
> day-to-day language? The purpose of language is to transmit information, so it is usually a good idea to use common words
> that leave no room for ambiguity.
>
> Ironically, the other meaning of "artefact" is "any error in the *perception or representation of any information*, introduced
> by the involved equipment or technique(s)" [Wikipedia]

I'm with Hans on this.

The underlying problem is that we have run out of words that mean 'thingamajig'.

“When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master—that's all.”

Every time you want a 'thingamajig', it is different thing and you have not only to define it (easy-ish), but get that definition into the mind of the reader (much more difficult) and until you achieve the latter, you will leave the user confused.

Choosing a word like 'artefact' that has multiple customary meanings is asking for more confusion.

It's tricky because all the words you might chose have another definition already from some other application and so are 'taken' in peoples' minds.

No specific suggestions have popped into my mind.

But it would be better to call it 'thing' than artefact!

Paul

PS '$(>)'  really, really turns me off :-(



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
replies inline

On 30 November 2017 at 13:28, Stefan Seefeld via Boost <
[hidden email]> wrote:

> On 30.11.2017 06:57, Richard Hodges via Boost wrote:
> > This discussion will eventually lead to the realisation that a
> cross-platform builder tool requires separate concepts for (amongst others):
> >
> > * source files
> > * libraries (dynamic and static)
> > * dependencies
> > * executables built for the target system
> > * executables built for the build host (i.e. intermediate build tools)
> > * scopes
> > * -D macro definitions
> > * abstractions of compiler options
> > * abstractions of build host fundamental operations (environment
> variables, file existence, file copying, file locks, spawning subprocesses
> etc)
> >
> > … and so on.
>
> What's your point ? I think everyone understands that.
>
>
My point is that I think it would be useful to focus on this reality in
priority to a wrapper around bjam.


> > To short-circuit the discussion I can offer the following observations:
> >
> > * bjam, clever as it is, is basically a form of makefile. It will never
> be a build tool It’s therefore not useful to anyone but boost maintainers
> or single-target projects.
>
> That sounds like a rather unsubstantial rant. Can you elaborate on what
> you mean by that ?
>

bjam does what makefiles do. It computes and executes configurable
dependency tree. It remains up to the developer know the specific flags,
tools, settings etc he needs to build for a given target on a given host.
This is also true of a makefile. bjam and make are functionally equivalent
in that they offer no abstraction in statement of intent.


>
> >
> > * makefiles are great for creating dependency graphs. They are suitable
> for the output or intermediate stages of a build tool. You build a makefile
> hierarchy from the build tool abstractions given a target toolset and
> options.
> >
> > We already have Scons and CMake, which are both awful in their own way.
> >
> > I really think that effort would be better spent retro fitting python
> (or javascript, or [insert well maintained scripting language here]) into
> cmake so that cmake becomes beautiful.
> >
> > Either that, or recreate cmake in python (or javascript), but cleanly,
> using the combined knowledge of several years of evolution.
> >
> > Why the cmake team chose to build their own godawful scripting language
> is a mystery to me. I suspect someone just wanted to write a DSL one day
> and it all got way out of hand (original poster, please take note!)
> >
> > R
>
> Sorry, but I still don't understand what you are trying to say. (I don't
> agree that CMake would be great if it used a better language. I think it
> is flawed on multiple levels. The fact that it wants to be a build
> system generator rather than a build system probably being the central
> issue.)
>

The abstract build system generator feature of cmake is what makes it
uniquely useful to me (and half* the world)

>
> But, to get back to the original topic (which was the Faber
> announcement): have you looked at it (either the docs or the code) ? Can
> you substantiate your claim that it doesn't meet the points in your
> shopping list above ?
>
> I have looked at the docs an the code. You cannot describe a c++ project
in abstract terms with faber, just as you cannot with bjam or make. You
still need to know the exact command line options to set for your
particular compiler and target system.

System discovery of build host and target is very important. This is why
gnu autotools was created. The complexity of gnu autotools I suspect was
the driver for the creation of scons and cmake. They are better, but not
good enough.

We don't need** another make. make et-al are good enough for managing
dependencies. We do need** a better, more intuitive means of describing a
project and its dependencies in a platform-agnostic manner.


Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
> * "half the world" - is a rough finger-in-the-air estimate of the
population of c++ developers who need more than a simple makefile (i.e.
most of them).

** my opinion


>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 30.11.2017 07:32, Paul A. Bristow via Boost wrote:

>
>> -----Original Message-----
>> From: Boost [mailto:[hidden email]] On Behalf Of Hans Dembinski via Boost
>> Sent: 30 November 2017 10:52
>> To: Stefan Seefeld
>> Cc: Hans Dembinski; [hidden email]
>> Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
>>
>>
>>> On 29. Nov 2017, at 14:31, Stefan Seefeld <[hidden email]> wrote:
>>>
>>> On 29.11.2017 07:59, Hans Dembinski wrote:
>>>>> from faber.artefacts.binary import binary
>>>>>
>>>>> greet = module('greet')
>>>>>
>>>>> hello = binary('hello', ['hello.cpp', greet.greet])
>>>>>
>>>>> rule(action('test', '$(>)'), 'test', hello, attrs=notfile|always)
>>>>>
>>>>> default = hello
>>>>>
>>>>> (from
>>>>> https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript
>> <https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript>),
>>>>> which uses higher-level artefacts (`binary`, `library`) and doesn't
>>>>> require the user to define his own actions to build.
>>>> This example remains cryptic.
>>>>
>>>> from faber.artefacts...: artefacts? The term "artefact" is very general and non-descriptive. The first definition provided by
>> Google is essentially "human-made thing".
>>> Right, it's what "faber" generates (using the same stem even).
>> :) Fair enough, but it is still not very descriptive. Why use an uncommon latin word if you could use a common word from
>> day-to-day language? The purpose of language is to transmit information, so it is usually a good idea to use common words
>> that leave no room for ambiguity.
>>
>> Ironically, the other meaning of "artefact" is "any error in the *perception or representation of any information*, introduced
>> by the involved equipment or technique(s)" [Wikipedia]
> I'm with Hans on this.
[...]

(Yes, I'm fully aware of the difficulties of defining and establishing
terminology. :-) )

> But it would be better to call it 'thing' than artefact!

Ah, no. Because with "artefact" I really use the original (etymologic)
meaning: something created. Think of yourself as "homo faber" in that
ontology :-)

>
> Paul
>
> PS '$(>)'  really, really turns me off :-(

Sorry for that. That's a bit of inheritance from bjam, but can easily be
changed. Or we could add aliases such as $(in) and (out), or whatever
people prefer.

I have to admit that I bit frustrated that we spend so much time talking
about naming and syntax, rather than the more fundamental stuff like
design or functionality. Is that merely because it's easy to find syntax
issues, but arguing about design requires more time to understand the
thing under review ? I really don't want to get stuck in bikeshed
discussions after having spent so much effort on Faber's infrastructure
to correct what I perceived as major flaws in b2's design. . :-(


Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Announcement: Faber, a new build system based on bjam

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi Richard,

I'm going to use "b2" rather than "bjam" in my reply, as it really is b2
(or "Boost.Build", if you prefer) that we need to look at here, and
which Faber draws from. bjam is indeed little more than a "dependency
graph manager". B2 layers lots of important concepts over that,
including tools and tool abstractions, features and their mapping to
(tool-specific) parameters, etc.
So I assume you really mean b2 when you criticise "bjam" below...

On 30.11.2017 07:50, Richard Hodges via Boost wrote:

> replies inline
>
> On 30 November 2017 at 13:28, Stefan Seefeld via Boost <
> [hidden email]> wrote:
>
>> On 30.11.2017 06:57, Richard Hodges via Boost wrote:
>>> This discussion will eventually lead to the realisation that a
>> cross-platform builder tool requires separate concepts for (amongst others):
>>> * source files
>>> * libraries (dynamic and static)
>>> * dependencies
>>> * executables built for the target system
>>> * executables built for the build host (i.e. intermediate build tools)
>>> * scopes
>>> * -D macro definitions
>>> * abstractions of compiler options
>>> * abstractions of build host fundamental operations (environment
>> variables, file existence, file copying, file locks, spawning subprocesses
>> etc)
>>> … and so on.
>> What's your point ? I think everyone understands that.
>>
>>
> My point is that I think it would be useful to focus on this reality in
> priority to a wrapper around bjam.

That's because b2 already *does* support all of the above concepts. And
while they may not be very intuitive to use (hence my focus on a new
"frontend"), I believe that on a conceptual level I can reuse most of
what b2 has to offer, including features, tools, and much more.
So I'd like to ask you to substantiate your claim that these concepts
aren't provided or served adequately by b2 / faber.

>>> To short-circuit the discussion I can offer the following observations:
>>>
>>> * bjam, clever as it is, is basically a form of makefile. It will never
>> be a build tool It’s therefore not useful to anyone but boost maintainers
>> or single-target projects.
>>
>> That sounds like a rather unsubstantial rant. Can you elaborate on what
>> you mean by that ?
>>
> bjam does what makefiles do. It computes and executes configurable
> dependency tree.

It does much more. It defines features and tools, then automatically
detects the build platform and available tools, lets users fine-tune
those, and only then maps a platform-agnostic build description (in form
of a set of Jamfiles or fabscripts) and maps that to a concrete
dependency graph with concrete actions.

>  It remains up to the developer know the specific flags,
> tools, settings etc he needs to build for a given target on a given host.

You only need to know the specific tools and their argument spelling if
the automatic mapping performed by faber doesn't suite you, and you want
to fine-tune the specific commands. But the general premise of faber (as
well as b2) is that it separates the task of defining tools and the task
of defining build logic, as the two are done by quite different sets of
people.

>
>> But, to get back to the original topic (which was the Faber
>> announcement): have you looked at it (either the docs or the code) ? Can
>> you substantiate your claim that it doesn't meet the points in your
>> shopping list above ?
>>
>> I have looked at the docs an the code. You cannot describe a c++ project
> in abstract terms with faber, just as you cannot with bjam or make. You
> still need to know the exact command line options to set for your
> particular compiler and target system.

Huh ?
Counter examples:
https://github.com/stefanseefeld/faber/blob/develop/examples/implicit_rules/fabscript
https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript
https://github.com/stefanseefeld/faber/blob/develop/examples/test/fabscript
https://github.com/stefanseefeld/faber/blob/develop/examples/config/fabscript

Where do you see any mention of "exact command line options" in these ?
The first two would even cross-compile out of the box (when compiled
with `faber target.arch=something`), and the latter two only can't
because they need to execute compiled code, and cross-configuration and
cross-testing isn't quite supported yet.


Stefan

--

      ...ich hab' noch einen Koffer in Berlin...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123