Hi,
On Sat, 29 Jun 2002, Keith Owens wrote:
> What happens when you want to support multiple source trees?
First we should answer the question, why kbuild support for multiple
source trees is such a must have feature? So far I haven't seen a
satisfying answer, that would justify a big increase in kbuild complexity.
Only very few people would need such a feature and often there are other
ways to archive almost the same.
If such a feature is really badly needed, I think it's better to implement
it first as a seperate tool, which synchronizes multiple source dirs into
a single dir. This is not as efficient, as kbuild has to recheck the
single dir, but most of it should be in the cache, so it shouldn't be that
bad. On the other hand it should be easy to integrate in whatever kbuild
system. If there should be a huge demand for a better integration, we can
still do this later.
> What happens when the config data is not in monolithic files but is
> supplied in per-driver files (driver.inf)? Linus wants that feature
> eventually. Note that driver.inf will contain more than just config
> data, it will contain all the data required to build a driver. With
> your approach every CML program would have to be changed to understand
> the format of the driver.inf files, replicating the code over multiple
> parsers. With my approach you need one program that extracts the
> relevant data for config and builds the config tree, then the existing
> CML programs run unchanged.
The simple answer is to replace all the parsers with a single library,
which is what I'm currently working on. Maintaining multiple config
formats is just silly.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 30 2002 - 22:00:14 EST