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/fabscri...), 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/...
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...