On 2018-03-11 23:54, Enrico Maria Crisostomo wrote:
>> However, when we are going to add more templates, lots of options will
>> be repeated in each of them. If we are later going to change any of
>> these, we have to do this in all templates. I am not sure how much of a
>> problem that will be.
>> Also, such a template approach will never allow to combine different
>> features, like using github port group for fetching, but the python port
>> group for building the port.
> The prototype uses just one monolithic template, but I'd expect the following
> to be true:
> * Templates may not need to be one per possible output, they could be finer
> grained and get concatenated.
> * Dynamic content could be generated and interleaved with template output,
> if necessary.
> I think I share your feelings about templates, and I have little idea about
> how complex the output can/should be.
I just wanted to point out what the limitations of this approach could
be. Maybe we should not worry too much about it. It is totally fine if
some ports are too complex for this script, because it is meant to cover
the most common cases and will never work for all software projects out
Another thing this script could do would be to fetch and extract the
distfile and try to guess the build system by checking for the existence
of "configure", "Makefile", "CMakeLists.txt", etc. and set up the
configure/build/destroot phases accordingly.
Maybe at some later point we could even try to merge this with scripts
like pypi2port, that use the language-specific package manager to fill
the list of dependencies of modules. Then we could have a single
interface for all these generators. But that is really for much later,
let's start with the easy tasks.