Bert Huijben wrote on Thu, Jun 23, 2011 at 23:31:42 +0200: > > > > -----Original Message----- > > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > Sent: donderdag 23 juni 2011 23:26 > > To: Bert Huijben > > Cc: 'Greg Stein'; dev@subversion.apache.org > > Subject: Re: svn commit: r1132968 - in > > /subversion/trunk/subversion/include: svn_types.h svn_version.h > > > > Bert Huijben wrote on Thu, Jun 23, 2011 at 22:59:47 +0200: > > > > > > > > > > -----Original Message----- > > > > From: Greg Stein [mailto:gst...@gmail.com] > > > > Sent: donderdag 23 juni 2011 22:30 > > > > To: Bert Huijben > > > > Cc: dev@subversion.apache.org > > > > Subject: Re: svn commit: r1132968 - in > > > > /subversion/trunk/subversion/include: svn_types.h svn_version.h > > > > > > > > On Thu, Jun 23, 2011 at 15:47, Bert Huijben <b...@qqmail.nl> wrote: > > > > >> -----Original Message----- > > > > >> From: Greg Stein [mailto:gst...@gmail.com] > > > > >> Sent: donderdag 23 juni 2011 21:01 > > > > >> To: dev@subversion.apache.org > > > > >> Subject: Re: svn commit: r1132968 - in > > > > >> /subversion/trunk/subversion/include: svn_types.h svn_version.h > > > > >> > > > > >> On Tue, Jun 7, 2011 at 08:14, <rhuij...@apache.org> wrote: > > > > >> > Author: rhuijben > > > > >> > Date: Tue Jun 7 12:14:14 2011 > > > > >> > New Revision: 1132968 > > > > >> > > > > > >> > URL: http://svn.apache.org/viewvc?rev=1132968&view=rev > > > > >> > Log: > > > > >> > Following up on r1132965, just move the type. This matches how we > > > > >> handled the > > > > >> > problem for svn_error_t. > > > > >> > > > > > >> > * subversion/include/svn_types.h > > > > >> > (svn_version_t): Add full definition here. > > > > >> > > > > > >> > * subversion/include/svn_version.h > > > > >> > (svn_version_t): And remove it here. > > > > >> > > > > >> I've been thinking more on this change and absolutely hate it. > > > > >> > > > > >> We have a header DEDICATED to this structure and its concepts. The > > > > >> structure should be in that header file. It makes no sense to have > a > > > > >> dedicated header, yet to move its key structure somewhere else. > > > > >> > > > > >> Please revert this change. > > > > > > > > > > We also have a header file dedicated to svn_error_t and yet it is > > > defined in > > > > > svn_types.h. > > > > > > > > Yes. We wanted to avoid recursive includes, per the comment attached > > > > to svn_error_t. That is because svn_error_t is used within > > > > svn_types.h. > > > > > > > > svn_version_t is NOT used within svn_types.h, so there is no need to > > > > disentangle recursive #includes. > > > > > > > > > The fact that you personally hate it doesn't add any weight to your > > > other > > > > > arguments. > > > > > > > > > > I don't see any other strong opinions on this and as you try to > teach > > > > > everyone on this list Apache doesn't have per project dictators who > say > > > > what > > > > > can, can't and must be done. With a veto we ask for a different > solution > > > in > > > > > order not to stall the project. > > > > > > > > I'm not a dictator, and I didn't attempt to veto this. I'm asking you > > > > to revert a change that myself and a few others disagree with. > > > > > > > > I dunno what a "different solution" would be because the move of the > > > > structure didn't solve any problems. > > > > > > > > > What solution do you suggest for having a header included everywhere > > > > that > > > > > changes on every tag? > > > > > > > > Huh? My svn_version.h hasn't changed since June 9th, when I pulled > > > > down this change. It never changes for us developers. > > > > > > > > > Can we move the defines that change to a different header that isn't > > > > > included everywhere? > > > > > What kind of forward (typedef) would work to allow keeping the > > reduced > > > > set > > > > > of includes? > > > > > > > > I really don't know what defines you're talking about that change. > > > > > > > > > I just did what you did in early 1.7 development: reduce the number > of > > > > > recursive header includes and this one really helps in the build > time: > > > > > Especially for third party projects building on top of Subversion. > > > (Which we > > > > > currently ask to follow trunk) > > > > > > > > I don't understand the third party angle here. What does that have to > > > > do with the placement of the svn_version_t structure? > > > > > > The defines I'm talking about are > > > > > > (I'm not interested in these as these don't change that often, but I add > > > them here for completeness) > > > #define SVN_VER_MAJOR 1 > > > #define SVN_VER_MINOR 7 > > > #define SVN_VER_PATCH 0 > > > > > > But most importantly > > > #define SVN_VER_TAG " (under development)" > > > #define SVN_VER_NUMTAG "-dev" > > > #define SVN_VER_REVISION 0 > > > > > > These are redefined by third party distributions that somehow influence > > how > > > Subversion is built to make it visible to their users that they are not > 100% > > > the official build. > > > > > > These defines are in svn_version.h while only the files that currently > > > explicitly include svn_version.h really need these defines. > > > > > > All our svn_*.h files except for the very global ones implemented in > > > libsvn_subr have at least one function that returns a svn_version_t * to > > > allow runtime version checks, so these headers used to include > > svn_version.h > > > just to get this typedef. > > > (r1132968 made it possible just to include just svn_types.h, which any > > > header file has to do anyway) > > > > > > Changing the defines as part of an incremental build (after an svn > update) > > > > #ifndef SVN_VER_TAG > > #define SVN_VER_TAG " (under development)" > > #endif > > This would work if I had a way to build just the .c files that need this > define. >
As I asked on IRC, is there (or could we have) a single header that you touch(1) at the time you change the value of the macro in the build script? > To get the same result I would have to rebuild all .c files to get the > defines in the right place, or the new value would just be ignored in an > incremental build. > Err, if you ignore the value in an incremental build and compile only some libraries than the version checking (at DLL load time) will blow up. Been there, done that -> tools/dev/windows-build/document-version.pl > Bert >
