On Sun, Oct 10, 2010 at 19:34, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: > On Sun, Oct 10, 2010 at 4:28 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: >> On Sun, Oct 10, 2010 at 4:15 PM, Ãvar ArnfjÃrà Bjarmason >> <avarab@xxxxxxxxx> wrote: >>> On Sun, Oct 10, 2010 at 13:20, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: >>>> lib/poll.c and lib/poll.in.h imported from 0a05120 in >>>> git://git.savannah.gnu.org/gnulib.git >>> >>> Having fought with importing things from gnulib myself using their >>> tools it would be useful to note in the commit message *how* you >>> imported this. Did you use the gnulib command with some archane >>> options so it wouldn't touch the build system while it was at it, or >>> did you just copy the relevant files manually? >>> >> >> Sorry if that was unclear - I just copied the files (verbatim). >> Patching to make it compile for us comes in the next patch. >> >> I didn't even know that there was a gnulib tool to extract code, but a >> quick google-search shows that there is. I'll look into using the tool >> instead for the next round. >> > > I've had a quick look at it, and it really doesn't seem like > gnulib-tool is suited for us here. It seems to be intended on pure > autoconf-projects, and starts including all kinds of things that we > don't need. We only care about poll-emulation on Windows, and we don't > need autoconf to tell us if it should be used or not. The only reason I asked was that I tried to use gnulib-tool at one point and reached the same conclusion. But in my case I wanted it to resolve dependencies (i.e. bring in multiple projects), so not using it was its own pain. I just thought I'd ask in case you'd spent more time on getting it to work. > So I'm not in favor of using gnulib-tool, and going with the current > method of verbatim copy with a separate fix-up commit. But perhaps I > should clarify the commit message so other people can easily upgrade > the emulation later... By all means don't use gnulib, but noting how to upgrade things when we add anything external in compat/ is a good idea. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html