Menu
▾
▴
libusb-devel
|
From: Michael P. <mic...@gm...> - 2010-12-04 03:11:20
|
Segher Boessenkool wrote: >> >>> Yup, those files should be marked as binary -- we don't want to see >> >>> diffs >> >>> of big auto-generated XML-like files anyway. >> > >> > Well, the VC6 files are not XML. (*.dsp/dsw) >> >> I said XML-like, not XML -- aren't those files a big semi-hierarchical >> list of almost not manually edittable gobbledy-gook? Not at all, though the newer versions (*.sln/vcproj) are. They are vaguely similar to a makefile, though you certainly ought to be more careful editing them since they have to be parsed back in (unlike a makefile). And *I* certainly want to see diffs. >> >>> I still don't understand why in your configuration those are checked >> >>> out as CRLF, but other text files are just LF >> > >> > Oh, they are all CRLF in Windows; I just don't use those files in Windows, >> > so no issue. I do use them in Linux, but I have git configured >> > differently >> > there. I use gcc in Linux, and Microsoft in Windows, so I'm ok with those >> > files going whichever way you want (presumably LF, as I suggested). >> >> So for you, the issue is that those files go weird for git, even though you >> never touched them? Ho hum. No, those files are fine. The files that Pete marked CRLF in his gitattributes are the ones that actually "go weird". And I do need to touch them, though the problem arises even if I don't. Michael |
|
From: Michael P. <mic...@gm...> - 2010-12-05 19:32:32
|
Segher Boessenkool wrote: >> > Is it necessarily bad to have CR's in the repository? >> >> For text files? Yes, absolutely. I'm seriously beginning to think this is the root of my problem. I think both Pete's and my working copies have CRLF's, but my repo has LF's and Pete's has CRLF's. I'm not 100% sure, but does that seem like a reasonable guess to you? Thanks, Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-05 20:24:07
|
On 2010.12.05 19:32, Michael Plante wrote: > I'm seriously beginning to think this is the root of my problem. I think > both Pete's and my working copies have CRLF's, but my repo has LF's and > Pete's has CRLF's. I'm not 100% sure, but does that seem like a reasonable > guess to you? If you didn't apply [1], which also converted all the project files in the repo then, yes, as I tried to point out, your files would still be LF'd in the repo (while mine are CRLF'd). Another possibility is that git is not smart enough to detect that if a .gitattributes is part of a commit, it should create it first and apply its settings (and I guess I should have broken my commit there, as I did break it up for official), so even as the patch operation should have converted the files in your repo, it didn't, and you would have had to unix2dos them right after. Regards, /Pete [1] http://git.libusb.org/?p=libusb-pbatard.git;a=commit;h=b5820d34ad6fd3fa719d861daa58e25789ccf232;js=1 |
|
From: Segher B. <se...@ke...> - 2010-12-06 13:20:02
|
>>> > Is it necessarily bad to have CR's in the repository? >>> >>> For text files? Yes, absolutely. > > I'm seriously beginning to think this is the root of my problem. I think > both Pete's and my working copies have CRLF's, but my repo has LF's and > Pete's has CRLF's. I'm not 100% sure, but does that seem like a > reasonable > guess to you? It's certainly possible. Segher |
|
From: Graeme G. <gr...@ar...> - 2010-12-06 02:56:16
|
Michael Plante wrote: > Is it necessarily bad to have CR's in the repository? There are certainly > some files that should be that way in the snapshot (and also some that > should be LF-only in the snapshot). In particular, for the snapshot, I'd > like to see the MSVC stuff, source files, and documentation as CRLF, and the > bash/autotools/make-specific stuff as LF. As I've noted before, there is no reason that everything can't be LF only line ending. The only "nice" reason to use CRLF is to allow Notepad to work on .txt, .inf etc. files. Graeme Gill. |
|
From: Michael P. <mic...@gm...> - 2010-12-06 02:59:36
|
Graeme Gill wrote: >> Michael Plante wrote: >> > Is it necessarily bad to have CR's in the repository? There are certainly >> > some files that should be that way in the snapshot (and also some that >> > should be LF-only in the snapshot). In particular, for the snapshot, I'd >> > like to see the MSVC stuff, source files, and documentation as CRLF, and the >> > bash/autotools/make-specific stuff as LF. >> >> As I've noted before, there is no reason that everything can't be LF only >> line ending. The only "nice" reason to use CRLF is to allow Notepad to >> work on .txt, .inf etc. files. Hrm? The question was about the repository, not the working copy. Notepad sees the working copy. (But yes, as mentioned elsewhere, notepad and windiff are my primary reasons.) Michael |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 03:26:27
|
On Mon, Dec 6, 2010 at 10:59 AM, Michael Plante <mic...@gm...> wrote: > Graeme Gill wrote: >>> As I've noted before, there is no reason that everything can't be LF only >>> line ending. The only "nice" reason to use CRLF is to allow Notepad to >>> work on .txt, .inf etc. files. > > > Hrm? The question was about the repository, not the working copy. Notepad > sees the working copy. (But yes, as mentioned elsewhere, notepad and > windiff are my primary reasons.) Do we really care about Notepad? As for Windiff, I am not sure. But there are tools which works with LF line endings. Actually I do not understand why we have such a long thread, as Orin and others have pointed out the LF works for the VStudio. And then binmode is recommended by Cygwin as pointed by Segher. So why not make everything LF and do not allow MSysGit to act smart and convert anything. In that case, everything would be fine. I think this is the easiest and pragmatic solution. I use Cygwin git and never have any issues with various git repositories, some of them cross-platform. I usually use Notepad++ to view text file under Windows. -- Xiaofan |
|
From: Michael P. <mic...@gm...> - 2010-12-06 03:45:25
|
Xiaofan Chen wrote: >> Michael wrote: >> > Hrm? The question was about the repository, not the working copy. Notepad >> > sees the working copy. (But yes, as mentioned elsewhere, notepad and >> > windiff are my primary reasons.) >> >> Do we really care about Notepad? It would seem I'm repeating myself multiple times in this thread, but having to do so here is a bit absurd, given that you quoted the answer to your own question: yes. Also, at least at one point, Orin did, too: http://libusb.6.n5.nabble.com/libsub-1-0-for-Windows-MSVC-tp6305p6415.html >> Actually I do not understand why we have such a long thread, I didn't get up this morning and say "I want a long thread." Neither did Pete, I'm sure. We respond until we either agree or get tired of arguing. So...I'm not sure I understand why it matters. Ignore it if you're not interested in the outcome. Believe it or not, you missed a few off-list responses on certain tangents. If all you look at is the length, then sure, it's all going to be statistics. But if you read the thread's content, then it should hopefully make sense. Regards, Michael |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 05:00:30
|
On Mon, Dec 6, 2010 at 11:44 AM, Michael Plante <mic...@gm...> wrote: > If all you look at is the length, then sure, it's all going to be > statistics. But if you read the thread's content, then it should hopefully > make sense. > No it does not make sense to me. But anyway, I can understand the situation now. The Windows integration is stalled, and people have nothing better to do than trying to be a git expert... Sorry but I can help jumping to such a conclusion... -- Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 04:53:20
|
On Mon, Dec 6, 2010 at 11:44 AM, Michael Plante <mic...@gm...> wrote: > Xiaofan Chen wrote: >>> Do we really care about Notepad? > > It would seem I'm repeating myself multiple times in this thread, but having > to do so here is a bit absurd, given that you quoted the answer to your own > question: yes. Also, at least at one point, Orin did, too: > > http://libusb.6.n5.nabble.com/libsub-1-0-for-Windows-MSVC-tp6305p6415.html > Orin mentioned that "Yes, me too. Often for things like bat and inf files!" Take note the "bat and inf files". I would do that too. -- Xiaofan |
|
From: Orin E. <ori...@gm...> - 2010-12-06 06:40:50
|
On Sun, Dec 5, 2010 at 8:53 PM, Xiaofan Chen <xia...@gm...> wrote: > On Mon, Dec 6, 2010 at 11:44 AM, Michael Plante > <mic...@gm...> wrote: > > Xiaofan Chen wrote: > >>> Do we really care about Notepad? > > > > It would seem I'm repeating myself multiple times in this thread, but > having > > to do so here is a bit absurd, given that you quoted the answer to your > own > > question: yes. Also, at least at one point, Orin did, too: > > > > > http://libusb.6.n5.nabble.com/libsub-1-0-for-Windows-MSVC-tp6305p6415.html > > > > Orin mentioned that "Yes, me too. Often for things like bat and inf > files!" > Take note the "bat and inf files". I would do that too. > Actually, it's my first choice if I have file of unknown type as it's relatively benign if you give it a binary file. It hasn't been the case when I've accidentally used more in a Linux shell window - flashing text if I'm lucky - invisible text if I'm not! As for the .ds?, .vcproj and .sln files, these are _opaque_ files that you shouldn't be poking around in. Sure, we happen to know that some are text with <CR><LF> line endings. IMO, whatever the OS, this SHOULD NOT be changed. You SHOULD NOT be editing them with a tool that does not preserve the <CR><LF>. They should be treated as binary files, but since we know they are text with <CR><LF> line endings, I don't see a problem with treating them as text files that always have <CR><LF> line endings _as an optimization_. As I recall, the problem I had was that git gave me files with <LF> line endings, Visual Studio didn't care, but wrote out lines with <CR><LF> endings and then Peter complained when a patch had some <CR>s in it. BTW, I'm not a fan of <CR><LF> line endings, so please don't interpret the above as such. Orin. |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 06:52:51
|
On Mon, Dec 6, 2010 at 2:40 PM, Orin Eman <ori...@gm...> wrote: > As for the .ds?, .vcproj and .sln files, these are _opaque_ files that you > shouldn't be poking around in. Sure, we happen to know that some are text > with <CR><LF> line endings. IMO, whatever the OS, this SHOULD NOT be > changed. You SHOULD NOT be editing them with a tool that does not preserve > the <CR><LF>. They should be treated as binary files, That is exactly what I mean. They should be treated as binary files and binmode is the preferred way to deal with them. > but since we know > they are text with <CR><LF> line endings, I don't see a problem with > treating them as text files that always have <CR><LF> line endings _as an > optimization_. > I know sometimes people edit the files as a quick hack (say to use VS2005 on VS2008 projects) but in the case of libusb repo, I think they should be treated as binary files. -- Xiaofan |
|
From: Segher B. <se...@ke...> - 2010-12-06 12:58:11
|
>> As for the .ds?, .vcproj and .sln files, these are _opaque_ files that >> you >> shouldn't be poking around in. Sure, we happen to know that some are >> text >> with <CR><LF> line endings. IMO, whatever the OS, this SHOULD NOT be >> changed. You SHOULD NOT be editing them with a tool that does not >> preserve >> the <CR><LF>. They should be treated as binary files, > > That is exactly what I mean. They should be treated as binary files > and binmode is the preferred way to deal with them. I think that way causes fewest problems, yes. Segher |
|
From: Graeme G. <gr...@ar...> - 2010-12-01 23:09:09
|
Segher Boessenkool wrote: > People who build from source will get an error "you need a newer > version of autoconf", so that's no problem either. It's a problem if you are the one getting the error! (Boy I'm glad I don't use autoconf or libtool. Lots of developer time seems to get wasted updating them at very frequent intervals. This is odd given that the underlying build environments are not changing.) Graeme Gill. |
|
From: Segher B. <se...@ke...> - 2010-12-01 19:32:37
|
>> libusb-stuge.git is the current state of my working tree. That is >> rebased frequently, but I only expect one split in there for now, >> and a few commit message changes. If anyone wants to review these >> commits, even if they will still change a little further, please go >> for it! I'll take into account any and all comments in my further >> work. > > libusb-stuge broke cygwin compilation. > > Getting the following when running configure from autogen.sh: > > ... > checking for sys/time.h... yes > configure: creating ./config.status > .in'ig.status: error: cannot find input file: ` > > Yup, the last line is verbatim. Wow, that's... special? What on earth is going on there! > And I'm going to rant again, but was it really necessary to split the > configure.ac changes into 9 commits? What good will come of going atomic > with such single liners as "Quote AC_COMPILE_IFELSE() input" or "Trivial > whitespace changes and reordering", *REALLY*? There are lots of big advantages to having small, independent patches for independent problems / improvements. I agree it doesn't make much sense to spend lots of time on pulling apart bigger patches; but if you can make them as small commits _in the first place_, it is _less work in total_ even. And, in this case, I know for a fact that some of those were created as these three-liners (I suggested one of-em, the quoting thing -- newer autoconf complains without it). Segher |
|
From: Peter S. <pe...@st...> - 2010-12-01 20:26:12
|
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. :\ //Peter |
|
From: Peter S. <pe...@st...> - 2010-12-02 00:09:47
|
Pete Batard wrote: > >>> libusbi.h:831: error: parse error before "nfds_t" .. > > 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 thought the problem was with the configure check, but thinking a little further about this I actually don't need those files because in fact the configure test is working correctly - just that Cygwin should be an exception. > 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. No. Cygwin is making things a bit complicated for us, because it provides a poll() which I believe we don't want to use. Right? I was thinking that nfds_t was being incorrectly detected, but it is of course available in Cygwin, and libusbi.h doesn't pull in the header that defines it. While that happens to be correct on Windows it is actually a bug which should also be fixed. I think it belongs in the same commit. > 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? //Peter |
|
From: Peter S. <pe...@st...> - 2010-12-02 01:53:56
|
Pete Batard wrote: > 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... Yep. I've changed the commit a bit, and my current tree is now in the libusb-stuge.git branch called testing. I've reset my master back to the libusb.git state and will move on to clean up Trac later, maybe not until next week. Please grab the testing branch, I hope it'll fix this problem. Here's the new commit: http://git.libusb.org/?p=libusb-stuge.git;a=commitdiff;h=fac692f //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-02 11:46:27
|
On 2010.12.02 01:53, Peter Stuge wrote: > Please grab the testing branch, I hope it'll fix this problem. Looks good, thanks! Still have the shadow warnings (patched in my branch, so you'll get it when this exercise has been applied to official and I can submit the new batch of Windows patches) and: dpfp_threaded.c: In function `poll_thread_main': dpfp_threaded.c:95: warning: control reaches end of non-void function for which I had sent a quick patch 2 months ago [2]. I think there was a shadowing of the errcode global variable when compiling MinGW, which you'll also pick a fix for when I submit a new set of patches. Regards, /Pete PS: As far as logistics are concerned, unless stuge-testing is sorted out and integrated into official within the next 10 days, I don't think I'll have the ability to submit a proper (i.e. tested on all Windows environments) set of Windows patches against official before January. |
|
From: Pete B. <pb...@gm...> - 2010-12-02 11:47:41
|
[2] (no idea why it's not [1]) http://marc.info/?l=libusb-devel&m=128637757004632&w=2 /Pete |
|
From: Pete B. <pb...@gm...> - 2010-12-02 11:56:08
|
Also, if you're adding .gitattributes [1], can you please add "*.sh eol=lf" in it (or at least autogen.sh). Otherwise, any cygwin user picking the repo from git needs to convert autogen.sh Regards, /Pete [1] http://git.libusb.org/?p=libusb-stuge.git;a=commit;h=24a36dfccc7f7c4a9107b701fdde29bf879aa5db;js=1 |
|
From: Pete B. <pb...@gm...> - 2010-12-02 12:12:45
|
Finally, it looks like if you have both the .gitattributes and configure.ac changes in the same commit, you still get CRLFs, because obviously the .gitattributes does not apply to this pull yet. To be safe, (and I can't believe I'm advocating this), this commit should be broken down. Regards, /Pete |
|
From: Pete B. <pb...@gm...> - 2010-12-02 12:11:24
|
On 2010.12.02 12:04, Pete Batard wrote: > To be safe, (and I can't believe I'm advocating this), this commit > should be broken down. Or, more likely, it's the use of eol=lf instead of -crlf I remember trying eol=lf and getting nowhere with it [1]. Please use -crfl, so that *we* are in control of line terminators on files where it matters. Regards, /Pete [1] http://git.libusb.org/?p=libusb-pbatard.git;a=commitdiff;h=d5032f4e537ddf5636b78238e2266261935c4b84;js=1 |
|
From: Peter S. <pe...@st...> - 2010-12-01 19:39:11
|
Pete Batard wrote: > > libusb-stuge.git is the current state of my working tree. .. > libusb-stuge broke cygwin compilation. Thanks for testing it! Awesome! > .in'ig.status: error: cannot find input file: ` > > Yup, the last line is verbatim. Crazy. :) I'll follow up to the other messages. This one is more about the process. > And I'm going to rant again, but was it really necessary to split > the configure.ac changes into 9 commits? Yes, absolutely. They are distinct changes, and they were not all split after the fact. Any time a commit needed to be split, it was because I had made a mistake and/or not planned or prepared well. > What good will come of going atomic with such single liners as > "Quote AC_COMPILE_IFELSE() input" or "Trivial whitespace changes > and reordering", *REALLY*? Again, distinct changes, they may or may not be applied. git is quite able to deal with many commits, and high commit resolution allows us to get the most out of git. > IMO, a simple "configure.ac improvements" with bullet points detailing > each improvements could do wonders, especially as configure.ac is far > from being our bread and butter. 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. Very difficult to review, and I think not acceptable at least for anything in libusb core. As for backend-specific changes I will try to follow Daniel's lead and go with whatever patches are sent. > If producing such commits has been taking time away from > progressing on the actual official integration for 1.0.9, > maybe we need to review our approach... It is very much a part of the work to prepare the next release. The many commits is how I work, and also how I expect others to work; because it allows us to take full advantage of git, and because it is logical, which makes it easy for others to follow. One change = one commit. 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. :) //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-03 13:01:55
|
On 2010.12.03 10:59, Xiaofan Chen wrote: > What if you not using msys-git/TortoiseGit? For one I do not > use them and I use Cygwin git. It works the same as git under > Linux. In that case, maybe things would work better for you. Please understand that we are not trying to address a problem that only affects me here, even if I'm the only one to have reported it so far. We are trying to address a problem that *will* potentially affect all TGit/msys-git users even if they switch to different gits afterwards, including Linux. As far as my testings are concerned, any user of Tgit/msys-git using default settings should be affected, and that's not something we can fix upstream. Even if you later switch to using cygwin or even Linux git on the directory you cloned with Tgit/msys-git, you will get issues [1], so basically that means either not using Tgit/msys-git or making sure that you change your default options before you even attempt to clone a directory. If someone is new to git (yes, you can be both new to git AND want to participate in libusb internal development), they're unlikely to be aware of the problem. Sure, we could point the issue out on our website, but that's just a selfish approach IMO - see the end of my e-mail. Even if I was the only person affected, "don't use tool X, use tool Y instead" seems like poor advice when we know exactly how to fix the issue for tool X, especially when it's a 10 secs fix. When something's difficult to fix with tool X, advocating switching to tool Y may be good advice. That is not the case here. 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! But let me elaborate a little bit on where I come from here. Unless you are omniscient and know for certain that this fix will introduce problems that will result in more time spent by the libusb developers to fix them than the collective amount of time that is going to be wasted by libusb users having to switch/upgrade/fix their tools, then you should go for the fix, because the expectation is that, for what looks to me as a very selfish reason (spare some of *your* time by placing an unneeded burden on others), you are likely to deprive your users of the very same valuable resource, and more damagingly, to a greater collective amount, especially if you aim your project at becoming a de-facto standard of accessing USB devices on all the major platforms. That's the precise reason I pushed so hard for the CJK libtool fix, that's the reason I will push again to have xusb and MSVC projects included, regardless of what the maintainers want, as the equation is very simple: If you know that implementing something will take some or potentially a lot of your development time, but you suspect that not doing it will force your users to collectively waste a larger amount of time, then it becomes *criminal* not to do it when you have the capacity to do so. Not providing xusb (which we have the capacity for - it's already there) = time wasted for users who want something with more meat than lsusb. Not having MS project files (same) = time wasted for MS users that have either to recreate or download them for a separate source, etc. That's how libusb should work IMO and also why, for instance, we should also be fast-tracking things like hotplug (capacity wise, it's pretty much already there too!), because there is actual demand for it, and, unlike what is the case for libusb-win32, there doesn't exist an alternative, which results in time wasted (working around or doing their own implementation) by our users. Regards, /Pete [1] http://pete-tech.blogspot.com/2010/12/that-darn-libtoolize-acconfigmacrodirm4.html |
Thanks for helping keep SourceForge clean.
X