From: Segher B. <se...@ke...> - 2010-12-03 13:35:56
|
> And I'm really starting to wonder how committed we are to our users when > it looks like, there again, we are reluctant about introducing *simple* > 30 seconds fixes in our tree, and instead foster the "upgrade your tools > / don't use tool X" approach. We know exactly how to avoid the issue, > and it's trivial to fix, so let's help our users instead of placing yet > another set of demands on them dammit! I don't think anyone is against that simple .gitattributes patch; it is safe enough for "sane" platforms. People are worried about the *actual* problem though: somehow your git port and also the rest of your build environment is in two minds about what a line ending looks like. This is quite likely to cause a lot of other problems as well. I would say that .gitattributes -crlf thing is fine, but I don't really want to see twenty other patches to support messed-up code checkouts ;-) Segher |
From: Pete B. <pb...@gm...> - 2010-12-03 13:54:21
|
On 2010.12.03 13:35, Segher Boessenkool wrote: > I would say that .gitattributes -crlf thing is fine, but I don't really > want to see twenty other patches to support messed-up code checkouts ;-) If twenty other patches is expected to result in more time spared for all our users than the amount of time we'll spend adding them, then I find it would be extremely selfish of us not to go with these 20 patches. We're not writing software for us. We're writing it for our users. Regards, /Pete |
From: Segher B. <se...@ke...> - 2010-12-03 17:09:11
|
>> I would say that .gitattributes -crlf thing is fine, but I don't really >> want to see twenty other patches to support messed-up code checkouts ;-) > > If twenty other patches is expected to result in more time spared for > all our users than the amount of time we'll spend adding them, then I > find it would be extremely selfish of us not to go with these 20 > patches. We're not writing software for us. We're writing it for our > users. And the best way to help your users in that case is to tell them to fix their environment, not keep piling on workarounds until the whole thing collapses under its own weight. That's all hypothetical of course; the .gitattributes thing is fine. Segher |
From: Pete B. <pb...@gm...> - 2010-12-02 00:38:35
|
On 2010.12.02 00:09, Peter Stuge wrote: >> Now, properly including poll.h without breaking things is going to >> require some time, > > Actually autoconf makes it trivial. But I don't think this is the > problem for Cygwin. > > Do we want to use Cygwin's poll()? I think not - I'm not sure if it > will do what we want, or perform as well as poll_windows. I would be > happy with poll_windows also for Cygwin. What do you say? I think you're right, we're not using cygwin's poll in the first place, so that's why we have the issue. I kind of stopped my initial investigation of that issue when I got puzzled about the fact that there wasn't a special case for the inclusion of poll_windows.h in Makefile.am, and I should have made the link by then. So the issue then is that configure does detect that cygwin has poll, and nfds_t, but we've made sure we didn't use poll. That's actually why I had to define nfds_t in poll_windows.h (which the commit removed). So now we have to add a special case for cywgin. We could undef POLL_NFDS_TYPE and redef it to unsigned int in poll_windows.h, but that would look quite ugly. Better do it in configure.ac and get it defined right in the first place... Regards, /Pete |
From: Pete B. <pb...@gm...> - 2010-12-01 22:05:58
|
On 2010.12.01 20:26, Peter Stuge wrote: > Segher Boessenkool wrote: >>> CC libusb_1_0_la-core.lo >>> In file included from core.c:30: >>> libusbi.h:831: error: parse error before "nfds_t" >>> libusbi.h:831: warning: function declaration isn't a prototype >>> make[2]: *** [libusb_1_0_la-core.lo] Error 1 >> >> Looks like you don't include config.h in your OS files? > > Pete, please send also config.h along with config.log. > > Since libusbi.h has a #include<config.h> at the top (as it should) > it seems that the configure test failed to detect lack of nfds_t on > cygwin, although it worked on the older OS X. :\ NB it's not because I don't mention something that I haven't checked it. I did check that nfds_t was properly detected from configure, that the config.h defined it properly as a result, that it was included in linusbi.h and concluded that the piece that's missing is a #include <poll.h> in poll_posix.h. Now, properly including poll.h without breaking things is going to require some time, especially as I haven't really analysed all the latest changes that went into configure.ac (want to avoid a #ifdef __CYGWIN__ if not needed), so I that's why I am advocating just dropping the patch, unless you want to test all of MSVC, cygwin and MinGW yourself. Regards, /Pete |
From: Segher B. <se...@ke...> - 2010-12-01 19:45:00
|
> Peter, > > Can you tell where [1] comes from, I asked for it (it is needed on some OSX versions), Peter created it and tested it on at least Linux, I tested it on a few OSX versions. > and if this was ever tested on cygwin? Not many developers here (or on any other open source project) use mswindows. If everything was going smoothly, there would be a "proposed updates" branch in the main libusb.git repo, and you (and everyone) would test that, see something is wrong, report it, and it would be fixed. It's a lot less reasonable to expect you (or anyone) to keep track of what is happening in Peter's (or anyone else's) private repo! > If Windows specific patches like this one It's not an mswindows patch; in fact, the problem is that those old OSX versions grossly violate POSIX requirements here. > are being introduced without > being properly tested (haven't tested MSVC, since we don't have the > project files), this is going to be a major headache. > > Or at least, please submit it as a proposal to the list so that I can > try to test it. Yes, that would be good. I expect Peter will post all these patches before integrating them to mainline? > I'm only realizing now that you have added a lot of > changes in your tree that were never publicly debated on the list. He can do that _in his tree_ whenever he wants, no? :-) > I'm afraid keeping all of MinGW, MSVC and cygwin happy at the same time > is almost never straightforward, Well, if we can do it for all POSIX systems, ... ;-) > no matter how simple the patch might > look, so for now, I'd suggest we revert this change (if it ain't > broke...) How about you figure out why the patch doesn't work for you? It seems to me it will probably work again if you revert the patch to libusb/os/poll_windows.h; but if that works, it's only exposing deeper problems in the os/windows code (perhaps you're not including config.h, or you use nfds_t where you really just want int, or something). What is the actual error? Segher |
From: Segher B. <se...@ke...> - 2010-12-02 02:06:43
|
> If 9 months is what we want to affix with the label "obsolete", that's > not going to fly. Nine months old autoconf, agreed. Nine months old cygwin? I have no idea how old their tools are, if it's anything like OSX it's not good :-) > To me obsolete should not apply to anything that's > less than 2 years, because I fully expect people to use 2 year old > development platforms, especially on Windows. Two years is a bit long, but for most problems I would aim for around that yes. Also, note that it really isn't hard at all to install a newer autotools (from source) when you need it. >> The required version here >> would be two years old (if I understand correctly), an eternity! > > Nope. Found that my 1 year old autoconf 2.65 version (src released > 2009.11) wouldn't work either, Huh strange, so it's another bug than what Peter dug up. > Do you upgrade your autotools every 6 months? More often than that, but sure, that's not what you meant :-) Segher |
From: Pete B. <pb...@gm...> - 2010-12-02 02:55:43
|
On 2010.12.02 02:06, Segher Boessenkool wrote: > Nine months old autoconf, agreed. Nine months old cygwin? I have no > idea how old their tools are, if it's anything like OSX it's not good :-) Nothing else is like Apple's hardware or software. They've built their empire on making sure their users want/need to upgrade everything every 6 months ;) Also I hope Apple's development tools are not anything like iTunes, where you have to update the whole shebang every 2 weeks, for obscure reasons. More seriouslsy, given how MinGW and cygwin take a lot of involvement to install (especially MinGW-w64), I can't say I'm overjoyed at the prospect of having to reinstall 3 complete toolchains every 6 months just to satisfy the libusb development requirements, unless there is a bug that needs fixing. If you want a reference of what people will expect for an update cycle on Windows, you just have to look at the MSVC release cycle. Including the service packs, I think it's closer to 18 months than 9 months, and that would be what Windows users would expect for an upgrade cycle. > Also, note that it really isn't hard at all to install a newer autotools > (from source) when you need it. I beg to differ [1]. NB this was part of another "upgrading is easy/users should use the latest version of the tools" thread, but for libtool this time with, in this case, "obsolete" in the libusb sense meaning not yet officially released... ;) Regards, /Pete [1] http://marc.info/?l=libusb-devel&m=127187832930409&w=2 |
From: Orin E. <ori...@gm...> - 2010-12-02 07:31:20
|
On Wed, Dec 1, 2010 at 6:55 PM, Pete Batard <pb...@gm...> wrote: > > > If you want a reference of what people will expect for an update cycle > on Windows, you just have to look at the MSVC release cycle. Including > the service packs, I think it's closer to 18 months than 9 months, and > that would be what Windows users would expect for an upgrade cycle. > Hah! At work, I'm pretty much still on VC2005. In the Windows world, I think you'll find that tools aren't upgraded that often - changing tools means a new QA cycle and that costs time and money. > > > Also, note that it really isn't hard at all to install a newer autotools > > (from source) when you need it. > > It might not be hard, but it's always a step into the unknown - there is a chance that existing projects won't build properly with the newer toolchain. Just installed Visual Studio 2010 at work and what a pain that is - projects don't compile any more because they moved the global include and library paths out of the global VS configuration and made them per project, except they now have a well hidden file of your old settings that gets included and isn't editable from the UI. Orin. |
From: Xiaofan C. <xia...@gm...> - 2010-12-03 10:56:50
|
On Thu, Dec 2, 2010 at 10:55 AM, Pete Batard <pb...@gm...> wrote: > On 2010.12.02 02:06, Segher Boessenkool wrote: >> Nine months old autoconf, agreed. Nine months old cygwin? I have no >> idea how old their tools are, if it's anything like OSX it's not good :-) > > More seriouslsy, given how MinGW and cygwin take a lot of involvement to > install (especially MinGW-w64), I can't say I'm overjoyed at the > prospect of having to reinstall 3 complete toolchains every 6 months > just to satisfy the libusb development requirements, unless there is a > bug that needs fixing. > With the release of mingw-get, it is very easy to install and update MinGW. It is also quite easy to update Cygwin. As for MinGW-w64, I think it is a moving target and I do not think it is a problem to ask the users to reinstall it every 6 months or shorter. -- Xiaofan |
From: Segher B. <se...@ke...> - 2010-12-01 20:21:53
|
> Why, yes, it's the old "cygwin doesn't like multiple files to be > provided on multiple lines - YOU HAVE BEEN WARNED!" issue [1]. Why is that? Does it only work by accident on other systems? Have you tried quoting the whole argument? Like AC_CHECK_FILES([file1.h file2.h file3.h ... Or, use line continuations: AC_CHECK_FILE(file1.h \ file2.h \ ... > And I for one would like to place my vote into delaying all cosmetic > changes, like the above, until much later, and instead focus only on > what is really needed for the 1.0.9 release. It looks to me like Peter did this "cosmetic" change just to make any sense of the file ;-) > CC libusb_1_0_la-core.lo > In file included from core.c:30: > libusbi.h:831: error: parse error before "nfds_t" > libusbi.h:831: warning: function declaration isn't a prototype > make[2]: *** [libusb_1_0_la-core.lo] Error 1 Looks like you don't include config.h in your OS files? Segher |
From: Pete B. <pb...@gm...> - 2010-12-01 22:44:11
|
On 2010.12.01 19:39, Peter Stuge wrote: > Actually here the distinct commits help a lot, specifically *because* > we're still learning about configure.ac. It makes each step clear for > reviewers. You may already have noticed that several of the commits > touch the same code, and quite a lot of information about the way > from point A in the code to point B would have been lost if > everything was jammed into a single commit. I'm not talking about a single commit, but dealing with whitespaces and quotation could really be done in a single commit, especially when there's more to process. > Very difficult to review, Not really. I find it more difficult to find out where you guys are headed as it takes 9 commits to see the big picture. > and I think not acceptable at least for anything in libusb core. It is acceptable for configure.ac, especially if actual code is waiting. configure.ac is just a recepy, and none of the changes we're discussing here are changing even a single bit of the final libusb binary. single or multiple lines? not one bit. using an alias for nfds_t? not a sinle bit. I'm hard pressed to see how this benefits our users. > It is very much a part of the work to prepare the next release. How's that crucial to 1.0.9? Why could it not wait for 1.0.10 or 1.0.11 when there's more than enough patch submissions to keep us busy without even wanting to overhaul configure.ac? People are not waiting for us to release libusb with an overhauled configure.ac. They're waiting for hotplug, timestamped logging, libusb-win32 and all the good features we know we have to do, but that are ever delayed because we're chosing to waste out time on this "oh, but it will make things so much better if we do it now - just wait and see" crap. > One change = one commit. OK. I guess I'm going to start producing one commit for every option I change in the MS project files. Linux and OS-X people should be thrilled the day we have 9 commits in a row just for MS project files. > I rebased quite frequently making those changes, because I didn't > have a plan and was learning along the way, and because I discovered > more and more things to fix. This is why I like personal repos - > they're a sandbox, but still allow easy review so that the sandcastle > can be made even greater. :) Yeah, expect at the end of the day, you've only built your own little sandcastle model, and people have brought a ton of bricks for the actual house, that have been left untouched... Regards, /Pete |
From: Segher B. <se...@ke...> - 2010-12-01 23:20:30
|
> I'm not talking about a single commit, but dealing with whitespaces and > quotation could really be done in a single commit, especially when > there's more to process. Sure, but is there a problem with it being more commits? > configure.ac is just a recepy, and none of the changes we're discussing > here are changing even a single bit of the final libusb binary. single > or multiple lines? not one bit. using an alias for nfds_t? not a sinle > bit. Interesting examples you give there! You had separate problems with both these commits, remember? :-) > How's that crucial to 1.0.9? Why could it not wait for 1.0.10 or 1.0.11 > when there's more than enough patch submissions to keep us busy without > even wanting to overhaul configure.ac? That's a different problem. 1.0.9 is taking way too long, I certainly agree with that. But rolling everything into one mega-patch will not help; quite the opposite. > People are not waiting for us to > release libusb with an overhauled configure.ac. They're waiting for > hotplug, Won't be there, nothing has been written yet! > timestamped logging, Minor if you ask me; should be easy to merge, sure. > libusb-win32 Do you have that ready to merge? In an acceptable state? > and all the good features we > know we have to do, but that are ever delayed because we're chosing to > waste out time on this "oh, but it will make things so much better if we > do it now - just wait and see" crap. I don't know what is taking Peter so long, but this really isn't it. >> One change = one commit. > > OK. I guess I'm going to start producing one commit for every option I > change in the MS project files. Linux and OS-X people should be thrilled > the day we have 9 commits in a row just for MS project files. They will see just one merge commit, so they really won't care much. Most people wouldn't care anyway. There isn't any problem like this in *much* bigger projects, why would there be here? Just don't look at patches you're not interested in (but do test stuff on your platform, you're platform maintainer (if I understand that correctly) -- a thankless job, for sure. If stuff breaks, git bisect is your friend, whether there are a thousand patches or just ten). Segher |
From: Pete B. <pb...@gm...> - 2010-12-02 00:03:35
|
On 2010.12.01 23:20, Segher Boessenkool wrote: > Interesting examples you give there! You had separate problems with > both these commits, remember? :-) I'm well aware of that, which is why I think it should be obvious that, even as I had problems with split commits, I still don't see an advantage for them not being merged with another. How hard is it to point to a specific item in a commit that encompasses whitelines and quotation, when the whole commit would have been less than 15 lines total? Again, don't misconstrue what I have been saying into "these 9 commits should have been merged into one", because that's not what I said. > But rolling everything into one mega-patch will not help; quite the > opposite. Misread once again. Not talking about a mega patch. But merging set of < 5 lines commits each, that deal with configure.ac quotation and adding line feeds doesn't look that bad an idea to me >> timestamped logging, > > Minor if you ask me; should be easy to merge, sure. I'm sure people other than me will point out why timing info in libusb can be a boost to their troubleshooting. More often than once, I'm annoyed at not having this information myself. >> libusb-win32 > > Do you have that ready to merge? In an acceptable state? As I already mentioned many times, I need the existing Windows affairs to be resolved before I start looking into that. There's too much of what I've submitted that hasn't been accepted yet, or very much in the balance to have much incentive on producing a new development based on unstable ground. Once the gap between my branch and official has been reduced, I can get going. Some people expect small commits from all development. I myself expect firm ground before starting new development. My initial plan was to wait for an official realease with Windows, because we already have massive amounts of code to integrate, but I was overruled (someone will have to remind me how splitting small commits is good, but splitting releases when we have a very large amount of code is bad...) Without Release Early, Release Often being adopted by libusb, and since I value my development time (rebasing branches is not my idea of time well spent, especially if the breadth of changes is expected to be quite large) I think I'll wait for official to catch up with the current Windows branch, before introducing a new major Windows development. If you want new development for integration, I can submit a hotplug patch (for all platforms), but it doesn't look like the wise thing to do while the 1.0.9 elephant is still in the room. > They will see just one merge commit, so they really won't care much. > Most people wouldn't care anyway. There isn't any problem like this > in *much* bigger projects, why would there be here? Just don't look > at patches you're not interested in (but do test stuff on your platform, > you're platform maintainer (if I understand that correctly) -- a thankless > job, for sure. If stuff breaks, git bisect is your friend, whether there > are a thousand patches or just ten). As I said, I wouldn't care much for commits being split in 1000 pieces if our integration pace was the same as that of other *much* bigger projects. It's when things are dreadfully slow that I start to wonder if they have an impact. Regards, /Pete |
From: Segher B. <se...@ke...> - 2010-12-02 01:56:19
|
>> Interesting examples you give there! You had separate problems with >> both these commits, remember? :-) > > I'm well aware of that, which is why I think it should be obvious that, > even as I had problems with split commits, I still don't see an > advantage for them not being merged with another. How hard is it to > point to a specific item in a commit that encompasses whitelines and > quotation, when the whole commit would have been less than 15 lines total? That's assuming you do your testing manually. But I get your point, sure -- with the exception that these two problems both turn out to be pretty deep and not so terribly easy to solve. > Again, don't misconstrue what I have been saying into "these 9 commits > should have been merged into one", because that's not what I said. I misunderstood you then; my excuses. >> But rolling everything into one mega-patch will not help; quite the >> opposite. > > Misread once again. Not talking about a mega patch. But merging set of < > 5 lines commits each, that deal with configure.ac quotation and adding > line feeds doesn't look that bad an idea to me All *actually cosmetical* patches thrown together sounds like a good plan, yeah. But functional changes (like fixed quotation) should really be separate; and don't mix big cleanups with functional changes either, it makes it much harder to read and verify it is changing only the one thing. >>> timestamped logging, >> >> Minor if you ask me; should be easy to merge, sure. > > I'm sure people other than me will point out why timing info in libusb > can be a boost to their troubleshooting. More often than once, I'm > annoyed at not having this information myself. I would think this would be trivial to add; but now I realise you don't want to print the time at the time you print it, but print the time that something happened. >>> libusb-win32 >> >> Do you have that ready to merge? In an acceptable state? > > As I already mentioned many times, I need the existing Windows affairs > to be resolved before I start looking into that. It just sounded like you expected the fully merged stuff to be in 1.0.9, that's why I asked. > There's too much of > what I've submitted that hasn't been accepted yet, or very much in the > balance to have much incentive on producing a new development based on > unstable ground. Once the gap between my branch and official has been > reduced, I can get going. Let's hope things get going soon! > Some people expect small commits from all development. I myself expect > firm ground before starting new development. My initial plan was to wait > for an official realease with Windows, because we already have massive > amounts of code to integrate, but I was overruled (someone will have to > remind me how splitting small commits is good, but splitting releases > when we have a very large amount of code is bad...) If the changes are *only* to the mswindows code, I would think you can do whatever you want. It's probably good to let Xiaofan check it first (and whoever else cares); you should send a merge request to the mailing list, anyway. > Without Release Early, Release Often being adopted by libusb, What do you think a reasonable time between releases would be? Six months? Three months? Whenever enough stuff piled up? > and since > I value my development time (rebasing branches is not my idea of time > well spent, If you have to rebase a platform branch, it means it should already have been merged (i.e., it diverged too much). Not good :-( > If you want new development for integration, I can submit a hotplug > patch (for all platforms), but it doesn't look like the wise thing to do > while the 1.0.9 elephant is still in the room. Looking forward to it. But yeah, should probably push out a nice stable baseline first. >> They will see just one merge commit, so they really won't care much. >> Most people wouldn't care anyway. There isn't any problem like this >> in *much* bigger projects, why would there be here? Just don't look >> at patches you're not interested in (but do test stuff on your platform, >> you're platform maintainer (if I understand that correctly) -- a >> thankless >> job, for sure. If stuff breaks, git bisect is your friend, whether >> there >> are a thousand patches or just ten). > > As I said, I wouldn't care much for commits being split in 1000 pieces > if our integration pace was the same as that of other *much* bigger > projects. It's when things are dreadfully slow that I start to wonder if > they have an impact. I agree with that sentiment wholeheartedly. Segher |
From: Pete B. <pb...@gm...> - 2010-12-02 02:25:24
|
On 2010.12.02 01:56, Segher Boessenkool wrote: >> I'm sure people other than me will point out why timing info in libusb >> can be a boost to their troubleshooting. More often than once, I'm >> annoyed at not having this information myself. > > I would think this would be trivial to add; but now I realise you don't > want to print the time at the time you print it, but print the time that > something happened. Nah for now I think we'll just stick with the logging time. I think it should be fairly trivial too, but I don't think it's a good idea to add it before we've dealt with the existing backlog. Still, if you want something now, I can probably come up with something >>>> libusb-win32 >>> >>> Do you have that ready to merge? In an acceptable state? >> >> As I already mentioned many times, I need the existing Windows affairs >> to be resolved before I start looking into that. > > It just sounded like you expected the fully merged stuff to be in 1.0.9, > that's why I asked. To be frank, right now, I don't know what to expect of 1.0.9. Will it have MSVC project files? Will it have xusb? Will it have a def or something else? Will it have new enum? Can't tell until the patches submitted (or about to be resubmitted when the current commit breakdown exercise is complete) have been dealt with in an official manner. >> Without Release Early, Release Often being adopted by libusb, > > What do you think a reasonable time between releases would be? Six > months? Three months? Whenever enough stuff piled up? Last one no contest. The reason I am so frustrated right now is that I feel I've done everything I could to make it easy for the maintainers to integrate the Windows backend. I originally proposed a MinGW only implementation with pthread-win32 and WinUSB only to keep things simple and easy on the maintainers, and I regularly (I think it's 6 times now) posted a complete batch of Windows integration patches to the list, only to have them fall flat (i.e. neither rejected or approved - just sitting in limbo until they became out of sync with any branch and obsolete). Result, we now have more 150 KB of new code between 1.0.8 and 1.0.9, and this puts a strain on everybody. For a project the size of libusb, I'd say if you have more than 20 KB of new code, release, release, release!!! Regards, /Pete |