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. > > > 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.
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
