Created attachment 50114 [details] [review] Instead of using DBUS_INLINE, define "inline" to have its C99 meaning In commit b0b5f9b, Ralf added a workaround for compilers that don't understand the C99 inline keyword, but in fact this was never necessary for the Autoconf build system, because we use AC_C_INLINE. That macro causes config.h to #define "inline" to "__inline" or "__inline__" if the compiler understands one of those but not "inline", or to the empty string as a last resort (resulting in "static inline" functions becoming merely "static"), which means we can use "static inline" functions uniformly on any compiler. If CMake can't do that check, the next best thing is to check for MSVC++ specifically, resulting in: * Autoconf build system works with any C compiler * CMake build system works with MSVC++, or with any compiler that understands the inline keyword (in practice everyone is probably using MSVC++ or gcc) --- Ralf, could you check this for portability to MSVC, please?
This has already basically been done on master, in commit b1e28fba0bcb, so I omitted b0b5f9b when I merged dbus-1.4 into master. Please get patches reviewed as described in HACKING rather than just committing things, and please make pure bugfixes on the dbus-1.4 branch (and merge that branch into master) rather than cherry-picking.
Hi Simon, (In reply to comment #1) > This has already basically been done on master, in commit b1e28fba0bcb, so I > omitted b0b5f9b when I merged dbus-1.4 into master. > > Please get patches reviewed as described in HACKING rather than just committing > things, nice to hear that there are reviewers for the windows stuff :-) > and please make pure bugfixes on the dbus-1.4 branch (and merge that branch into master) rather than cherry-picking. Also if this issue is already fixed in master ? Does this case not need a backport ? > (and merge that branch into master) rather than cherry-picking. Which git command sequence should be used for does BTW: I tracked in the last month only the master branch and recognized some win32 compile errors in master, which i fixed first. After that I recognited different compile problems in dbus-1.4 which I fixed then.
(In reply to comment #2) > (In reply to comment #1) > > Please get patches reviewed as described in HACKING rather than just committing > > things, > > nice to hear that there are reviewers for the windows stuff :-) I'm aware that we're short of people who develop on Windows, but it seems better to have review from someone who doesn't fully understand Windows (e.g. me) than no review at all - particularly for things that touch cross-platform code, like this does. (Now that I've got Autoconf cross-compiling to mingw64 to work, I can at least compile Windows-specifics; one day the regression tests might even all pass under Wine...) > > and please make pure bugfixes on the dbus-1.4 branch (and merge that branch into master) rather than cherry-picking. > > Also if this issue is already fixed in master ? > Does this case not need a backport ? If a bug is fixed on master but not in dbus-1.4, then that means someone fixed the wrong branch :-) but yes you'd need to cherry-pick (and perhaps backport) in this case. > > (and merge that branch into master) rather than cherry-picking. > > Which git command sequence should be used for does git checkout master git merge dbus-1.4 fix the conflicts (usually just NEWS) git add ${the_files_that_had_conflicts} (or use git gui, like I do) git commit
(In reply to comment #0) > Instead of using DBUS_INLINE, define "inline" to have its C99 meaning For the record: fixed in git for 1.4.16 and 1.5.8 (I've merged it into master). Thank you for committing this, but if you apply patches from someone else (e.g. me in this case), could you please set the author to be the patch submitter and add a "Reviewed-by: you" pseudo-header, rather than the other way round? I didn't review this patch, I wrote it! For patches from Bugzilla that were produced with git format-patch, like all of mine, you can use something like "git am < 0001-Fix_some_stuff.patch" to apply the patch with authorship information, and "git commit --amend" to add the Reviewed-by. The other way to do patch review is to comment and say you've reviewed it and it looks OK, and the patch submitter can apply it themselves (this is what we normally do in Telepathy, if the patch submitter has commit access, since they usually know how to test the patch better than the reviewer does).
> Thank you for committing this, but if you apply patches from someone else (e.g. > me in this case), could you please set the author to be the patch submitter and > add a "Reviewed-by: you" pseudo-header, rather than the other way round? I > didn't review this patch, I wrote it! This is clear, but in this specific case I cherry-picked the related patch from master, so someone else is the author. Because your patch is identically you made the review :-) > For patches from Bugzilla that were produced with git format-patch, like all of > mine, you can use something like "git am < 0001-Fix_some_stuff.patch" to apply > the patch with authorship information, and "git commit --amend" to add the > Reviewed-by. > > The other way to do patch review is to comment and say you've reviewed it and > it looks OK, and the patch submitter can apply it themselves (this is what we > normally do in Telepathy, if the patch submitter has commit access, since they > usually know how to test the patch better than the reviewer does). Thanks for this hints.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.