On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote:
> Jon Loeliger wrote:
>> So, like, the other day Kumar Gala mumbled:
>>> Jon,
>>>
>>> It seems like have libfdt as a unique git repo that is a submodule of
>>> the things that need it (dtc, u-boot, etc.) might make some sense and it
>>> easier for the projects that need to pull it in.
>>>
>>> Is this something you can take a look at? (or have other ideas on).
>> I would be fine with making libfdt a git repository separate
>> from the DTC repository if that makes it easier to integrate
>> it with other projects.
I don't think it's a good idea to make dtc and libfdt entirely
seperate repositories (again). Being able to use both together in
their combined testsuite is very useful (libfdt is used to check trees
generated by dtc, dtc is used to generate example trees for libfdt
testing).
I'm not sure how submodules/subrepositories work so I don't know if
that makes sense.
> That sounds like a good idea to me. I would really prefer pulling patches
> out of a libfdt repo into the u-boot repo rather than trying to kerchunk
> upgrade lumps. While we can do this with a dtc repo, it potentially makes
> it a lot more difficult.
I don't think upgrading embedded copies by diff is a good way to go.
The upgrade method I had in mind was to pull out a whole new copy of
libfdt, drop that into the embedding project verbatim and generate a
new diff there in whatever their source tracking system is. I set out
the repository to make this easy.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
