Hi All, related to the discussion in this thread. I work with the following setup:
I run four build trees, one each of Debug and Release configuration for the latest branch and the development trunk. I call them 'bugfix' and 'dev' respectively. These are configured from two source trees (actually one in my case since I use git-svn and can switch between multiple branches and work in progress really easily in one source tree, but I would use two with svn). The four build trees are each configured to install into separate test directories so I can work on several things at once. For example I am often working on new stuff in dev that I debug build for testing and occasionally release build if there are packaging differences that I want to test. I also work on reported issues in the branch as a result of beta testing on the RC releases, these I debug build for personal testing and usually release build a package to send to the reporter of the issue for fix verification. For documentation I have the debug build location of the generated HTML bookmarked in my browsers so I can review it instantly after a build. This is why the debug configuration generates a fixed file name for the HTML so that my bookmarks don't get invalidated when the version name changes. I hardly ever blow away and reconfigure a build tree, I find the CMake dependency management really accurate and I am comfortable switching around branches and revisions in my source tree and simply rebuilding, I don't even run the clean target. Mulitiply this setup by three for Windows, Linux and Mac and you have a fair view of the setup for development I use. If the JTSDK reproduces anything like this, I think it would be an efficient tool for development for those that don't have to suffer the initial setup pain of a development environment. For almost everyone I would recommend only one of bugfix or dev which reduces the complexity by two straight off. As for having multiple platforms, that is only really needed for those working with platform dependent issues and a degree of masochism for suffering the defects and quirks of multiple operating systems along with managing all the security and o/s upgrades ;) BTW all of this, along with other projects I work on, lives on my i7 laptop running Windows 8.1 and using VirtualBox to host the other platforms. Building for release is done on the same hosts but I do have a separate single source and build tree on each build host for this which I do clean before an official release package build just to be certain the builds are absolutely repeatable. These ones are multiplied by six for Windows, Mac, Linux Debian 32/64-bit and Linux RPM 32/64-bit each on their own target machine so they can be sanity tested before release. 73 Bill G4WJS. On 31/05/2015 18:58, Bill Somerville wrote: > On 31/05/2015 18:45, KI7MT wrote: >> Hi Bill, > Hi Greg, > > I've just realized what you are doing. I didn't notice that you were > just configuring the doc directory and not the main build directory > above. That's not going to work! > > The configuration of the top level directory doesn't take long and > building the target 'docs' is only going to be marginally slower from > the top level. This is why I was surprised that you had a separate > install directory because I hadn't realized that you were only doing a > subset of the configuration. > > It seems that you are trying to make the documentation build faster by > skipping the top level configuration but the top level configuration > doesn't take more than a few seconds. > > I strongly suggest that you stick to a single build tree that is fully > configured from the top level and then just build the target you need > from that. > > 73 > Bill > G4WJS. > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
