On 30/10/2014 09:24, Bill Somerville wrote:
> On 30/10/2014 03:08, ki7mt wrote:
>> Hi Bill,
> Hi Greg,
>> Second one falied also:
>>
>> mkdir ~/src
>> cd ~/src
>> svn checkout svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx-superbuild
>> mkdir -p ~/build/wsjtx
>> cd ~/build/wsjtx
>> cmake -D WSJTX_TAG=branches/wsjtx ~/src/wsjtx-superbuild
>> cmake --build .  --target source
>>
>> Additionally, I didn't enable any verbosity, but, is the script building
>> any binaries during the source tar ball generation?
> Yes it is, it runs the default 'build' target before gathering the
> sources together. It's not very efficient and I could try and optimize
> it but OTOH I think I prefer a build to succeed before using publishing
> the source tarball. Currently the build is needed simply because that's
> the way that the WSJT-X part of the build gets the User Guide. I would
> need to add a special target to the WSJT-X just to get the User Guide to
> change this and was trying to minimize the changes needed to the main build.
I have optimized the WSJT-X superbuild to do the minimum required when 
making the source target. It still has to build hamlib as that is 
required before the WSJT-X target can be configured correctly.
>>
>> Error Log:
>> ----------------
>> Path: /home/ki7mt/build/wsjtx/wsjtx-prefix/src/wsjtx
>> Working Copy Root Path: /home/ki7mt/build/wsjtx/wsjtx-prefix/src/wsjtx
>> URL: svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
>> Relative URL: ^/branches/wsjtx
>> Repository Root: svn://svn.code.sf.net/p/wsjt/wsjt
>> Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79
>> Revision: 4569
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: bsomervi
>> Last Changed Rev: 4566
>> Last Changed Date: 2014-10-29 07:25:34 -0600 (Wed, 29 Oct 2014)
>> a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param
>> man.endnotes.are.numbered 0 --stringparam callout.graphics 0
>> --stringparam navig.graphics 0 --stringparam admon.textlabel 1
>> --stringparam admon.graphics 0  "/etc/asciidoc/docbook-xsl/manpage.xsl"
>> "/home/ki7mt/build/wsjtx/wsjtx-prefix/src/wsjtx-build/manpages/man/man1/wsjtx.1.xml"
>> returned non-zero exit status 5
>> make[6]: *** [manpages/man/man1/wsjtx.1.gz] Error 1
>> make[5]: *** [manpages/CMakeFiles/manpages.dir/all] Error 2
>> make[4]: *** [all] Error 2
> I don't have much idea what that error is, there doesn't seem to be any
> error message. A bit of googling implies that asciidoc looks online for
> stylesheets if they are not on the local machine. Have you got docbook
> installed? I don't know why the docbook manpage stylesheet online lookup
> failed but that is probably the issue.
The optimization above will avoid this error from a broken asciidoc 
installation since it doesn't have to build the manpages as part of the 
source target any more. A working asciidoc installation will still be 
required on the final build host.
>
> 73
> Bill
> G4WJS.
73
Bill
G4WJS.
>> On 10/29/2014 08:26 PM, Bill Somerville wrote:
>>> On 30/10/2014 02:18, ki7mt wrote:
>>>> Hi Bill,
>>> Hi Greg,
>>>> You may get this twice. Building the tarball fails.
>>> OK, answering this one because it is easier.
>>>> See below
>>> Ditto,
>>>> On 10/29/2014 12:41 PM, Bill Somerville wrote:
>>>>> Hi All,
>>>>>
>>>>> this is of relevance mainly to package maintainers who wish to produce
>>>>> packages for WSJT-X. It may also be relevant  to anyone who wishes build
>>>>> from source on *nix.
>>>>>
>>>>> Because the current generation of WSJT-X is built with a special version
>>>>> of hamlib I have created a small project that automates the correct
>>>>> build procedure for WSJT-X. Currently it only works on *nix systems and
>>>>> is mainly for use by package maintainers to simplify the process of
>>>>> building WSJT-X on a controlled build server.
>>>>>
>>>>> The issues addressed are:
>>>>>
>>>>> 1) Building everything needed that isn't provided already by a build
>>>>> host as standard or via pre-existing official packages,
>>>>> 2) Building a self-contained source package suitable for use on a build
>>>>> host with restricted or no Internet access. Combined with the recent
>>>>> changes to eliminate kvasd from WSJT-X Linux builds should make this
>>>>> option particularly attractive to Linux package maintainers who wish to
>>>>> submit packages to mainstream FOSS repositories.
>>>>>
>>>>> Option (1) builds Hamlib and WSJT-X by first fetching them from source
>>>>> control and then building them into an application. This can be used if
>>>>> the build server and distribution policies allow Internet access to
>>>>> upstream sources during the build process.
>>>>>
>>>>> Option (1) may also be used by casual builders who want a simplified
>>>>> build process for WSJT-X. ALthough it can be used for a "developer"
>>>>> build, this is not recommended as it may prove over restrictive when it
>>>>> comes to editing and committing any changes. For serious development of
>>>>> WSJT-X a piecemeal build approach with or without the aid of the
>>>>> JTSDK-QT is still preferred due to the extra flexibility facilitated.
>>>>>
>>>>> Option (2) is a two phase process, both using the superbuild project.
>>>>> The fist phase is similar to option (1) except that a target of 'source'
>>>>> is built. This generates a source tarball of the project itself that is
>>>>> augmented with the upstream sources that would be fetched from the VCS
>>>>> and the WSJT-X User Guide. This source tarball has everything that is
>>>>> needed to build WSJT-X without access to the Internet. The second phase
>>>>> runs when the unpacked source tarball is built as normal and would
>>>>> normally be run on the final target build host.
>>>>>
>>>>> Here is an example of an type (1) build:
>>>>>
>>>>>      $ mkdir ~/src
>>>>>      $ cd ~/src
>>>>>      $ svn checkout 
>>>>> svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx-superbuild
>>>>>      $ mkdir -p ~/build/wsjtx
>>>>>      $ cd ~/build/wsjtx
>>>>>      $ cmake ~/src/wsjtx-superbuild           # configure command
>>>>>      $ cmake --build .
>>>>>      $ sudo cmake --build .  --target install
>>>>>
>>>>> This should build the latest development version of WSJT-X and install
>>>>> it in /usr.
>>>>>
>>>>> If you wish to build a different revision you can specify an option
>>>>> WSJTX_TAG to the configure step above, for example to build the latest
>>>>> version of the WSJT-X v1.4 branch you would substitute:
>>>>>
>>>>>      $ cmake -D WSJTX_TAG=branches/wsjtx-1.4 ~/src/wsjtx-superbuild
>>>>>
>>>>> for the configure command above. You may also specify a tag to build a
>>>>> specific revision that has been tagged, e.g.:
>>>>>
>>>>>      $ cmake -D WSJTX_TAG=tags/wsjtx-1.4.0-rc3 ~/src/wsjtx-superbuild
>>>>>
>>>>> Now an example of a type (2) build:
>>>>>
>>>>> The first phase is very similar to a type (1) build with the exception
>>>>> that the target built is 'source', you can still build an 'install'
>>>>> target as well if you want to test the sources before publishing the
>>>>> source tarball. So let's say we want to build a self-contained tarball
>>>>> for WSJT-X v1.4.0 (which isn't tagged yet but will be when v1.4 is
>>>>> released):
>>>>>
>>>>>      $ mkdir ~/src
>>>>>      $ cd ~/src
>>>>>      $ svn checkout 
>>>>> svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx-superbuild
>>>>>      $ mkdir -p ~/build/wsjtx
>>>>>      $ cd ~/build/wsjtx
>>>>>      $ cmake -D WSJTX_TAG=tags/wsjtx-1.4.0 ~/src/wsjtx-superbuild
>>>>>      $ sudo cmake --build .  --target source
>>>> Followed the steps above, and it fails on the last steps. Test from the
>>>> error log.
>>>>
>>>> ---------------------
>>>> Cloning into 'hamlib'...
>>>> error: pathspec 'wsjtx-1.4.0' did not match any file(s) known to git.
>>>> CMake Error at
>>>> /home/ki7mt/build/wsjtx/hamlib-prefix/tmp/hamlib-gitclone.cmake:49
>>>> (message):
>>>>      Failed to checkout tag: 'wsjtx-1.4.0'
>>>> ---------------------
>>> Sorry about the sudo, not needed here but is in the install of the
>>> second phase unless an owned install prefix is specified.
>>>
>>> The reason for the failure is as I stated above, we have not tagged a
>>> v1.4.0 release yet. To test this now you will have to pick something to
>>> build that exists. The only choices at the moment are the two branches
>>> so you could use either:
>>>
>>> WSJTX_TAG=branches/wsjtx-1.4
>>>
>>> or
>>>
>>> WSJTX_TAG=branches/wsjtx
>>>
>>> sorry for any confusion but I wanted to use a realistic example since a
>>> real package would require a real release i.e. a tagged revision.
>>>>> This will generate a self-contained source tarball suitable for use on a
>>>>> different build host.
>>>>>
>>>>> For phase two you would transfer the source tarball generated above to
>>>>> the build host and proceed along the following lines:
>>>>>
>>>>>      $ mkdir ~/wsjt
>>>>>      $ cd wsjt
>>>>>      $ scp somewhere:build/wsjtx/wsjtx-1.4.0.tgz .
>>>>>      $ tar xzf wsjtx-1.4.0.tgz
>>>>>      $ mkdir build
>>>>>      $ cd build
>>>>>      $ cmake ../wsjtx-1.4.0
>>>>>      $ cmake --build .
>>>>>      $ sudo cmake --build --target install
>>>>>
>>>>> Which should build and install WSJT-X v1.4.0 into /usr, if you wish to
>>>>> install it somewhere else the configure step can include a
>>>>> CMAKE_INSTALL_PREFIX option as usual.
>>>>>
>>>>> Pre-built type (2) source tarballs will be included in future release
>>>>> publications ready for use as upstream source tarballs.
>>>>>
>>>>> Caveat: Type (2) builds with this project require WSJT-X revisions later
>>>>> than r4566 since there is a small change to the upstream WSJT-X sources
>>>>> to support local builds. This effectively means that this type of build
>>>>> is supported from WSJT-X v1.4.0-rc3 and wsjtx-1.5-devel onwards.
>>>>>
>>>>> 73
>>>>> Bill
>>>>> G4WJS.
>>>>>
>>> 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
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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

Reply via email to