On 01/06/2015 00:34, KI7MT wrote:
> Hi Bill,
Hi Greg,
>
> I've been at this for over an hour, and I cannot get the Version
> information into the file name using the docs target, it always
> returns the AsciiDoc file name only. The only thing I can conclude is,
> the Install step is what adds the {VERSION} 1.6.0-devel to the
> AsciiDoc file base name or there's something wrong with my invocation,
> but I don't what it is.
Oh dear, I seem to have somehow sent you an a wild goose chase :(
The original problem that Joe reported was nothing to do with the file
name, it was to do with the substitution of the {VERSION} attribute
inside the HTML user guide.
The *ONLY* problem was that the top level CMake script generates the
asciidoc config file with the VERSION attribute in it so the top level
CMake script *MUST* be used to configure the project build tree, even if
you only intend to build the docs target.
>
> I started from scratch (no build, install, config folders, nothing),
> and performed the following steps manually in JTSDK-QT.
>
> mkdir C:\JTSDK\wsjtx\build\release
> mkdir C:\JTSDK\wsjtx\install\release
> cd C:\JTSDK\:sjtx\build\release
>
> # Configure main build tree
> cmake -G "MinGW Makefiles" ^
> -D CMAKE_TOOLCHAIN_FILE=C:/JTSDK/scripts/wsjtx-toolchain.cmake ^
> -D CMAKE_BUILD_TYPE=Release ^
> -D CMAKE_INSTALL_PREFIX=C:/JTSDK/wsjtx/install/release ^
> C:/JTSDK/src/wsjtx
>
> # Run the build
> cmake --build . --target docs
>
> It builds the Doc, but the output file name, in the "Build Directory",
> is still wsjtx-main.html. And of course, there's nothing in the
> install directory.
That's correct. As I noted in a prior post the build document has the
generic name so that it can be bookmarked in a browser etc.
>
> I am at a loss as to how this should be built without running the
> Install target. I've attached the log for all the commands and their
> results.
The install target does indeed rename the file, it has to do that
because the installed executable references it in it's installed
location with the versioned file name (it also references it on the
project web server with the same name, which is now somewhat redundant)
when the help menu action "Local User Guide" is executed.
The build system does not make an executable in the build tree that will
access the user guide but it does make a user guide that can be
reviewed, the file name is not critical but it is helpful that it is
generic until it has to be named with the version for install and packaging.
>
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
>
>
> On 5/31/2015 12:39 PM, Bill Somerville wrote:
>> 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
