Difference between revisions of "Talk:Building"

From GnuCash
Jump to: navigation, search
(moved ancient slib note in here. Obviously it's about time to clean up the talk page too)
m (Notes for currently ongoing rewrite)
 
(8 intermediate revisions by 3 users not shown)
Line 6: Line 6:
 
Seems like aptitude is more robust and the wiki should be changed.
 
Seems like aptitude is more robust and the wiki should be changed.
  
== Ubuntu versions ==
 
  
=== fixing slib issues ===
+
This is distribution dependent and reference to specific package loading tools should be in the relevant distribution section.
 
+
Also library names can sometimes vary from distribution to distribution as well
On Ubuntu 10.04.1  the path for the guile.init file is a bit shorter than mentioned in the article:
 
 
 
          /usr/share/slib/
 
 
 
Thus line 1790  in my slib.scm  file reads:
 
 
 
(load-from-path "/usr/share/slib/guile.init")
 
 
 
hope that helps someone
 
  
 +
== Ubuntu versions ==
  
 
===Old Versions===
 
===Old Versions===
Line 31: Line 22:
 
Ok I finally deleted the old stuff, which leaves an orphaned wiki page: [[BuildGutsy]]
 
Ok I finally deleted the old stuff, which leaves an orphaned wiki page: [[BuildGutsy]]
 
When I get a chance and a fresh eye I will look over the instructions to make sure all parts been updated to assume git instead of svn. [[User:Twt|Twt]] 00:32, 6 February 2013 (EST)
 
When I get a chance and a fresh eye I will look over the instructions to make sure all parts been updated to assume git instead of svn. [[User:Twt|Twt]] 00:32, 6 February 2013 (EST)
 
=== Ubuntu 11.10: svn not found ===
 
 
On 2 November 2011 Phild wrote:
 
 
I was following the instructions for Ubuntu 11.10 which uses git, but during the "make" step I get an error almost immediately when it tries to run svn:
 
<pre>
 
svn log -v --xml -r HEAD:20021 http://svn.gnucash.org/repo/gnucash | \
 
  xsltproc --stringparam strip-prefix "gnucash/trunk" \
 
  --stringparam include-rev "yes" ./macros/svn2cl.xsl - > ChangeLog
 
 
/bin/bash: svn: command not found
 
</pre>
 
I thought that since we were using git it wouldn't use svn.  Any idea where I went wrong?
 
  
 
===Don't Copy and Paste Instructions===
 
===Don't Copy and Paste Instructions===
Line 61: Line 38:
 
Also just about everything will be identical between Debian and Ubuntu, so those sections can probably be merged. I'm making notes here and will try to get back soon to make a few changes. If someone else reading this has other thoughts please feel free to write them here. --19:17, 29 April 2014 (UTC)
 
Also just about everything will be identical between Debian and Ubuntu, so those sections can probably be merged. I'm making notes here and will try to get back soon to make a few changes. If someone else reading this has other thoughts please feel free to write them here. --19:17, 29 April 2014 (UTC)
  
== Building with make -jX  ==
+
Note from Clanlaw, 01 May 2014.  It was not me that said that.  In fact I think it is important that this should be as simple as possible for someone who may not be that IT savy to understand.  Remember that Ubuntu often has out of date versions of GnuCash and there needs to be simple instructions on how to build it.  Any changes must not compromise that.  Tidying up this document could make it more difficult to understand if not done carefully.
  
I had some trouble building gnucash for the past days and I couldn't for the life of me figure out why gnucash wouldn't build. I just added the -j2 options to try and speed up the compiling and when surfing around, this bug popped up:
+
===Notes for currently ongoing rewrite===
https://bugzilla.gnome.org/show_bug.cgi?id=644896
 
  
Would it be a good idea to make a note somewhere in the building section to specifically mention that gnucash doesn't support the -jX (X>1) feature?
+
* The new section mentions changes in the build system from autotools to cmake. It uses the precise 2.7.x versions to distinguish where the change happened. I prefer to avoid references to development releases. It may give the incorrect impression these versions are worth building still. They aren't as they are superseeded by the 3.x release. So I would propose to make the distinction on 3.x vs 2.6.x instead.
--[[User:Bert|Bert]] 17:46, 24 May 2011 (UTC)
+
* Also while cmake support was added to the 2.6 series around 2.6.13, I'm not fully confident it was completely without bugs. The 3.x series got much more attention in this respect. I would encourage building 2.6 with autotools still. Though that's my personal conservative opinion.
:Ok, but please keep in mind this restriction applies only to the "make install" step, not the "make" step. --[[User:Cstim|Cstim]] 06:56, 27 May 2011 (UTC)
+
* The new section mentions "Autotools make" and "Autotools make script" several times. This is ambiguous and should better be avoided. make is a tool on its own that can be used to drive the compilation, linking and installation of a program. It's not tied to autotools per se and it's not a script.
 +
* The whole distinction between autotools, cmake, make and ninja is a bit fuzzy in the current descriptions. autotools and cmake are 'build ''system'' configurators'. They prepare an environment in which tools like make or ninja can do their thing. It's worth expressing clearly autotools can only set up an environment for make, while cmake can do so for both make or cmake. make and ninja on the other hand are the tools actually drive the build itself. After running the proper make or ninja commands you'll have the application ready to run.
 +
* The two paragraphs on make and ninja make them appear much more different than they really are. The both do the same thing: compile sources, link them and install the end result. Ninja is a newer tool and indeed more efficient. But the "highly parallel" part is not a unique or distinguishing quality of the ninja tool. make is equally parallel in the cmake context. So I would just not mention that.
 +
* Perhaps "Building on linux distributions" is too strict, but I don't know how to formulate this better. Besides linux distributions, these instructions are also valid for environments like MacPorts and HomeBrew on Macos and several BSD variants. Setting up dependencies varies wildly, but the build instructions remain the same.
 +
* Apple has decided to rebrand Mac OS X to Macos. Should we update our documentation to reflect this ?

Latest revision as of 10:12, 21 September 2018

aptitude or apt-get

apt-get build-dep gnucash failed for me. aptitude build-dep gnucash worked Seems like aptitude is more robust and the wiki should be changed.


This is distribution dependent and reference to specific package loading tools should be in the relevant distribution section. Also library names can sometimes vary from distribution to distribution as well

Ubuntu versions

Old Versions

twt writes: Every time I look at this page I think about ditching the information for the old Ubuntu versions -- as you can see from the wikipedia page link I added awhile back, most of the old ones are not even supported by security updates and any serious person wouldn't be running them EXCEPT maybe to build an old version of GnuCash. So the only reason to keep them around would be "collective memory" -- "that's how we solved (whatever problem), back in the day."

I was wondering if there's a page for old outdated stuff like that. Next time I drop by I will look for it. IF not, maybe I will make one. Twt

I think you can safely remove the old stuff - it is always still available through the history. --Cstim 09:39, 18 February 2011 (UTC)
Ok thanks... I see some "interesting bits" I would like to retain (creating a .deb using checkinstall, for example, and maybe some of the old tricks), but NEXT time I get a few minutes I will clean things up as I suggested. --Twt 16:40, 25 March 2011 (UTC)

Ok I finally deleted the old stuff, which leaves an orphaned wiki page: BuildGutsy When I get a chance and a fresh eye I will look over the instructions to make sure all parts been updated to assume git instead of svn. Twt 00:32, 6 February 2013 (EST)

Don't Copy and Paste Instructions

TWT writes: I got a notice today -- 29 April 2014 -- that Clanlaw was here, who apparently said:

Note: Dear Ubunteros, please do not copy and paste whole paragraphs. Instead adjust single sections in the form

Version x and newer:
do this
Version x-1 and before:
do that.
Can someone of you clean up this chapter and later remove this note?

I like this suggestion -- in fact it looks like a lot of important hand-holding has been mixed in with the Ubuntu version-specific sections, and should be split out instead of making it look specific to Ubuntu. For example, the process for retrieving via git.

Also just about everything will be identical between Debian and Ubuntu, so those sections can probably be merged. I'm making notes here and will try to get back soon to make a few changes. If someone else reading this has other thoughts please feel free to write them here. --19:17, 29 April 2014 (UTC)

Note from Clanlaw, 01 May 2014. It was not me that said that. In fact I think it is important that this should be as simple as possible for someone who may not be that IT savy to understand. Remember that Ubuntu often has out of date versions of GnuCash and there needs to be simple instructions on how to build it. Any changes must not compromise that. Tidying up this document could make it more difficult to understand if not done carefully.

Notes for currently ongoing rewrite

  • The new section mentions changes in the build system from autotools to cmake. It uses the precise 2.7.x versions to distinguish where the change happened. I prefer to avoid references to development releases. It may give the incorrect impression these versions are worth building still. They aren't as they are superseeded by the 3.x release. So I would propose to make the distinction on 3.x vs 2.6.x instead.
  • Also while cmake support was added to the 2.6 series around 2.6.13, I'm not fully confident it was completely without bugs. The 3.x series got much more attention in this respect. I would encourage building 2.6 with autotools still. Though that's my personal conservative opinion.
  • The new section mentions "Autotools make" and "Autotools make script" several times. This is ambiguous and should better be avoided. make is a tool on its own that can be used to drive the compilation, linking and installation of a program. It's not tied to autotools per se and it's not a script.
  • The whole distinction between autotools, cmake, make and ninja is a bit fuzzy in the current descriptions. autotools and cmake are 'build system configurators'. They prepare an environment in which tools like make or ninja can do their thing. It's worth expressing clearly autotools can only set up an environment for make, while cmake can do so for both make or cmake. make and ninja on the other hand are the tools actually drive the build itself. After running the proper make or ninja commands you'll have the application ready to run.
  • The two paragraphs on make and ninja make them appear much more different than they really are. The both do the same thing: compile sources, link them and install the end result. Ninja is a newer tool and indeed more efficient. But the "highly parallel" part is not a unique or distinguishing quality of the ninja tool. make is equally parallel in the cmake context. So I would just not mention that.
  • Perhaps "Building on linux distributions" is too strict, but I don't know how to formulate this better. Besides linux distributions, these instructions are also valid for environments like MacPorts and HomeBrew on Macos and several BSD variants. Setting up dependencies varies wildly, but the build instructions remain the same.
  • Apple has decided to rebrand Mac OS X to Macos. Should we update our documentation to reflect this ?