There are two parts to this:
One is more experimentation. Finding gaps in the dcumentation and seeing what can be done at various levels is part of this. This is importsnt from a view of writing more recipes for specific use cases. In this case I can expect many failures ang going down routes which will turn out not be feasible.
The seocnd is more practical. I am looking at the GNU Make plugin as an example. The existing plugin as
makeOutputs as a way to specify input and output files in order for Gradle to perform up to date checks, It requires a person to know what the Makefile will produce and list them in the buildscript.
What I am trying is to build a model DSL that will not only allow a script author to specify the outputs, but also state what kind of artifact it is. For instance if the Makefile produces a shared library, then it would be nice for a native compoenents just to reference that library like it would for any other Gradle-built or prebuilt library. IN some or other way this will eventually require
getBinaries to work.
THe part I am looking at curretnly is the inputs. A
LanguageSourceSet which is modelled towards a set of well-known group of source files i.e.
*.cpp. With a Make project it is just an arbitrary set of files in a folder usually. I am not sure whether that is well modelled with a
LanguageSourceSet, this the experimentation to see if there is an alternative way of implementing it.
The current experiment, and you mentioning
BaseComponentSpec has lead me there, is to extend the internal
DefaultComponentSpec (from which
BaseComponentSpec derives anyway) and see how that works. I am not really concerned that
DefaultComponentSoec is internal at this point, for if the experiement works, there might be a valid case for having such a class in the API.