Re: vendor import questions
On Thursday, October 04, 2012 8:31:36 pm Brooks Davis wrote: On Tue, Sep 25, 2012 at 08:41:34AM -0400, John Baldwin wrote: On Monday, September 24, 2012 5:31:37 pm Brooks Davis wrote: As part of switching to NetBSD's mtree I plan to import their versions of a few files that are part of libc (for example all the bits of vis/unvis). I would like to do that via a vendor import, but I'm unsure where to put the files and how to tag them. For mtree itself the right place is clearly base/vendor/NetBSD/mtree/dist, but we don't seem to have a good example for libc bits. There is currently a base/vendor/NetBSD/dist directory containing a (very) partial source tree, but it seems to be unused in recent times. If I did import into that tree, the next question would be how to tag the import. The base/vendor/NetBSD/fparseln_19990920/ directory shows one seemingly sensible example, but I don't like the resulting explosion of top level directories. I also worry that having mixed versions in the libc directory would make any attempt at sensible merging difficult since we'd have to put mergeinfo on files. An additional issue is where to put the files in the source tree. Precedent seems to favor direct copies to src/lib/libc/gen etc. In some ways I think the optimal solution would be to put the bits in contrib in feature specific directories like contrib/libc/vis, but that might be annoying for some consumers. That being said, the existence if src/include means you can't simply check out libc so it's probably ok to add more locations in the source tree for a good cause. What's the right way to go here? libc already has contrib bits (contrib/gdtoa). I think something like contrib/NetBSD/libc/foo might be fine. The problem I have with just 'contrib/libc' is that it is ambiguous. OTOH, the contrib/NetBSD/libc path isn't too pretty either. One option would be to merge directly from the vendor area into src/lib/libc. One other option might be to just do src/contrib/vis if it is only for 'vis' files. I'm leaning towards src/contrib/libc-vis. That would also work well in vendor/NetBSD since I could do vendor/NetBSD/libc-vis/dist. I think that is fine. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: vendor import questions
On Tue, Sep 25, 2012 at 08:41:34AM -0400, John Baldwin wrote: On Monday, September 24, 2012 5:31:37 pm Brooks Davis wrote: As part of switching to NetBSD's mtree I plan to import their versions of a few files that are part of libc (for example all the bits of vis/unvis). I would like to do that via a vendor import, but I'm unsure where to put the files and how to tag them. For mtree itself the right place is clearly base/vendor/NetBSD/mtree/dist, but we don't seem to have a good example for libc bits. There is currently a base/vendor/NetBSD/dist directory containing a (very) partial source tree, but it seems to be unused in recent times. If I did import into that tree, the next question would be how to tag the import. The base/vendor/NetBSD/fparseln_19990920/ directory shows one seemingly sensible example, but I don't like the resulting explosion of top level directories. I also worry that having mixed versions in the libc directory would make any attempt at sensible merging difficult since we'd have to put mergeinfo on files. An additional issue is where to put the files in the source tree. Precedent seems to favor direct copies to src/lib/libc/gen etc. In some ways I think the optimal solution would be to put the bits in contrib in feature specific directories like contrib/libc/vis, but that might be annoying for some consumers. That being said, the existence if src/include means you can't simply check out libc so it's probably ok to add more locations in the source tree for a good cause. What's the right way to go here? libc already has contrib bits (contrib/gdtoa). I think something like contrib/NetBSD/libc/foo might be fine. The problem I have with just 'contrib/libc' is that it is ambiguous. OTOH, the contrib/NetBSD/libc path isn't too pretty either. One option would be to merge directly from the vendor area into src/lib/libc. One other option might be to just do src/contrib/vis if it is only for 'vis' files. I'm leaning towards src/contrib/libc-vis. That would also work well in vendor/NetBSD since I could do vendor/NetBSD/libc-vis/dist. -- Brooks pgp3NEa7WABu0.pgp Description: PGP signature
Re: vendor import questions
On Monday, September 24, 2012 5:31:37 pm Brooks Davis wrote: As part of switching to NetBSD's mtree I plan to import their versions of a few files that are part of libc (for example all the bits of vis/unvis). I would like to do that via a vendor import, but I'm unsure where to put the files and how to tag them. For mtree itself the right place is clearly base/vendor/NetBSD/mtree/dist, but we don't seem to have a good example for libc bits. There is currently a base/vendor/NetBSD/dist directory containing a (very) partial source tree, but it seems to be unused in recent times. If I did import into that tree, the next question would be how to tag the import. The base/vendor/NetBSD/fparseln_19990920/ directory shows one seemingly sensible example, but I don't like the resulting explosion of top level directories. I also worry that having mixed versions in the libc directory would make any attempt at sensible merging difficult since we'd have to put mergeinfo on files. An additional issue is where to put the files in the source tree. Precedent seems to favor direct copies to src/lib/libc/gen etc. In some ways I think the optimal solution would be to put the bits in contrib in feature specific directories like contrib/libc/vis, but that might be annoying for some consumers. That being said, the existence if src/include means you can't simply check out libc so it's probably ok to add more locations in the source tree for a good cause. What's the right way to go here? libc already has contrib bits (contrib/gdtoa). I think something like contrib/NetBSD/libc/foo might be fine. The problem I have with just 'contrib/libc' is that it is ambiguous. OTOH, the contrib/NetBSD/libc path isn't too pretty either. One option would be to merge directly from the vendor area into src/lib/libc. One other option might be to just do src/contrib/vis if it is only for 'vis' files. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
vendor import questions
As part of switching to NetBSD's mtree I plan to import their versions of a few files that are part of libc (for example all the bits of vis/unvis). I would like to do that via a vendor import, but I'm unsure where to put the files and how to tag them. For mtree itself the right place is clearly base/vendor/NetBSD/mtree/dist, but we don't seem to have a good example for libc bits. There is currently a base/vendor/NetBSD/dist directory containing a (very) partial source tree, but it seems to be unused in recent times. If I did import into that tree, the next question would be how to tag the import. The base/vendor/NetBSD/fparseln_19990920/ directory shows one seemingly sensible example, but I don't like the resulting explosion of top level directories. I also worry that having mixed versions in the libc directory would make any attempt at sensible merging difficult since we'd have to put mergeinfo on files. An additional issue is where to put the files in the source tree. Precedent seems to favor direct copies to src/lib/libc/gen etc. In some ways I think the optimal solution would be to put the bits in contrib in feature specific directories like contrib/libc/vis, but that might be annoying for some consumers. That being said, the existence if src/include means you can't simply check out libc so it's probably ok to add more locations in the source tree for a good cause. What's the right way to go here? Thanks, Brooks pgpuGw2DdOpQT.pgp Description: PGP signature
