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 there. 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. Rainer