On 11/13/2016 1:15 PM, Nick Østergaard wrote: > 2016-11-13 18:59 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com>: >> Hey Nick, >> >> The problem with the boost 1.61 bug fix in the master branch is that it >> includes c++11 code. That's why I didn't merge it into the stable >> branch. I want to avoid c++11 in the stable 4 branch so we will have to >> let package devs know that they cannot build kicad against boost >= >> 1.61. If someone can fix the boost context issue without using any >> c++11 code, I would accept a patch for that. > > Good. > >> >> I specifically changed the version string code to accept only two >> conditions for creating version strings. Case 1 is using git to >> generate the version string when KicadVersion.cmake is set to the >> default which it is current. Case 2 is that I (or the release manager) >> sets the version and branch settings in KiCadVersion.cmake which >> overrides the git version string. I don't want developers setting this >> as we have in the past. > > What do you mean by developers setting this? I don't think any > developers have set anything here.
Prior to the changes I made, you had to set KICAD_BUILD_VERSION and/or KICAD_REPO to generate a stable version string. Otherwise, you either go the git version string or no-vcs-found. This didn't work for package devs who expect the source archive to build with the appropiate version string without defining them at config time. > >> Apparently package devs hate it because they >> had remember to set the version and branch strings at config time when >> building from source archives otherwise they end up with no-vcs-found >> version string. > > Well, I have a hard time to see how the current solution in 4.0 is > addressing this issue. Does this mean that on the commit where you tag > it 4.0.5 will change the set( _wvh_version_str "no-vcs-found" ) with > set( _wvh_version_str "4.0.5" )? Once the version is set to something other than "no-vcs-found" in KiCadVersion.cmake, it takes precedence. What I plan on doing is setting it to 4.0.5 in the stable version tagged as 4.0.5 (hey that almost makes sense!). When I create the source archive, it wont be necessary to define KICAD_BUILD_VERSION or KICAD_REPO. Once that is complete, I will can change the version string in KiCadVersion.cmake to "4.0.6-pre" or something like that. >> I see Chris added this back into the master branch but >> I'm not sure I'm going to keep it. Developers should be using the >> version string generated by git and package devs should be using the >> version set in KiCadVersion.cmake. I can't see any reason for a third >> option. > > As it works in 4.0 now, I can't set -DKICAD_BUILD_VERSION=4.0.5_rc1. > It will still use the git version. > > I would expect to be able to override the version string in any case. > For example if I wanted to make a release candidate build to sort out > some packaging issues, it would be nice to see from the build that it > was a release candidate if anyone reports a bug on it. If you really need to be able to define the version at config time, I can leave Chris' recent changes assuming they didn't break the behavior of KiCadVersion.cmake. Do other projects allow changing the build version at config time? I got the feeling from some of the comments that this was "atypical". > >> >> I will be in an out all day today so if I don't reply I'm not ignoring >> you I've just got a full plate today and will respond as soon as I get a >> chance. >> >> Cheers, >> >> Wayne >> >> On 11/12/2016 11:55 AM, Nick Østergaard wrote: >>> Hi Wayne, >>> >>> Good news to see a new release, but I wonder about two things: >>> >>> 1. Boost 1.61 compatibility and bugfix? >>> 2. Release version string. >>> >>> Should the release should include the boost 1.61 fix. It was discussed in: >>> [Kicad-developers] About Bug 1604841: Pcbnew crash at moving via, and >>> boost::context fixes to make it compatible with boost 1.61 >>> >>> And there is a patch in [1], although it does not explicitly state >>> where it is from, but it looks similar to [2] and [3]. With out the >>> patch in [1] I can not build it against boost 1.62 on archlinux. >>> >>> Secondly, I would like to know how we are supposed to set the release >>> infor for the version string. For the 4.0.0--4.0.4 you are supposed to >>> use the following options to set the version string: >>> >>> -DKICAD_REPO_NAME=stable -DKICAD_BUILD_VERSION=4.0.5 >>> >>> But KICAD_REPO_NAME does not seem to exist anymore... even though I >>> set KICAD_BUILD_VERSION it gets overridden by the git info and the >>> version string becomes: >>> #define KICAD_FULL_VERSION "(2016-11-09 revision 18f77b8)-4.0" >>> >>> I would have expected to get something like we are used to as, >>> "4.0.5-stable" for example. >>> >>> Nick >>> >>> [1] >>> https://git.archlinux.org/svntogit/community.git/tree/trunk/boost-1.61.patch?h=packages/kicad >>> [2] >>> https://git.launchpad.net/kicad/commit/?id=06d4894fdbeb00727cdcc667b8899ad73d8eb1c2 >>> [3] >>> https://git.launchpad.net/kicad/commit/?id=78bc3c65de6c03d19be9902327d08cd4d87c229c >>> [4] https://lists.launchpad.net/kicad-developers/msg25556.html >>> >>> 2016-11-11 23:44 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com>: >>>> This is the last call for patches to the 4 stable branch. If I don't >>>> hear anything, I will set version string and tag 4.0.5 in the stable >>>> branch on Sunday and give our library, doc, translation, and package >>>> devs a couple of weeks to prepare before I make the official announcement. >>>> >>>> Thanks, >>>> >>>> Wayne >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : kicad-developers@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
