Jerone Young wrote: > So I forgot to CC all the interested parties on this list (sorry about > that I wasn't thinking at the time), but I did start up a conversation > on linuxppc-dev on the subject of splitting out libfdt from dtc. Mainly > to get the thought of what the dtc folks thought about splitting out > libfdt. > > The outcome of this discussion is the point of libfdt is to be > integrated into different projects. I could not make a good argument at > all as to why it should be split out (actually I did a terrible job at > it :-)). A good analogy was made also as this is "equivalent to > splitting libcrypto out of openssl". > > So the concessious from others in the libfdt community is the it should > go in the project. This would be in line with what Hollis has been > saying on the list. > > Now for us we can do one of the following options: > 1) Integrate libfdt into our kvm-userspace > or qemu (which would then require going upstream qemu folks also agree). > > 2) Can use wget or something to first grab the dtc source and get libfdt > from it. Then place in our make file and build it. As well as point > cflags & ldflags to it. (This can be done, though I wanted to avoid > going this route) > >
We definitely won't make the build so complicated as to depend on wget and Internet connectivity, so we'll just plant the tree in kvm-userspace.git. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
