To follow up on my original point about installing to custom-locations being non-obvious.
I just updated this building page, adding a section for installing to a custom location: http://sawfish.wikia.com/wiki/Compilation_from_GIT#Installing_to_a_Custom_Path Also titled the debian specific sections so non debian users don't get confused. On Thu, Apr 5, 2012 at 8:56 PM, Campbell Barton <[email protected]> wrote: > On Thu, Apr 5, 2012 at 4:57 PM, Teika Kazura <[email protected]> wrote: >> Campbell, *please* don't reply to a wrong thread. If you do choose >> to reply, you've got to change the title, and delete some headers, >> reply-to:, references: etc. I think it's easier to send a new one, >> rather than replying. > > You reply hints at not needing to build (using packages or only > building in some cases), > yet the point of the original discussion is about getting new > developers who by definition need to build. > > So this shouldnt be just about building, rather documenting a setup > for developers - which dev libs, which stable libs, what tools work > well, editor settings, code style guide etc. > >> On Thu, 5 Apr 2012 10:32:08 +1000, Campbell Barton wrote: >>> https://ideasman42-dev-scripts.googlecode.com/svn/trunk/install_scripts/inst_sawfish.sh >> >> I don't think there's reason to build the latest git Sawfish for >> most. Neither for librep and rep-gtk; they don't get so many updates. >> Stable releases suffice. > > The thread was on how to get new developers so - not "for most". > > It isn't clear to me if you can use the lastest sawfish-git with > stable libreb and rep-gtk, such matters should be covered in docs for > new developers. > for all I know changes are put into rep-get that sawfish depends on > (once in a while at least). > >> One reason to try the latest is to join the development. In that case, >> I don't recommend git clone, but pull. > > Ah, I wasn't aware of that. > >> I also recommend to read >> the logs or new ML posts to see what's happening before >> installation. So "building all three automatically by a single script" >> idea doesn't intrigue me. (Neither for other packages which you're not >> especially interested in. It's a waste of time. Stay stable.) > > Agree in respect to only building packages if you are prepared to be > involved somewhat - reading commit logs, reporting, helping fix > problems, etc. > > However there IS value in using the latests state of an application, > you find when things break and are able to test new features, For > users who are prepared to test the bleeding edge builds and report > bugs - I dont see why this would be discouraged. > >> And, there's no reason, _at all_, to avoid the use of the package >> manager of your distro. (Do you install Sawfish to an embedded >> system?) Those who build from the latest git especially should use >> the package manager. > > IMHO this is beside the point, if someone wants to build from source > to become involved with development, this should be made as > straightforward as possible (via docs and automation where useful), of > course if they only want to use, package managers are fine. > > > On a different tact, you could document how YOU develop sawfish so > others can use it as a basis. > > I did this for my IDE setup and also made a video > > http://wiki.blender.org/index.php/User:Ideasman42/CMakeQTCreatorLinux > > http://www.youtube.com/watch?v=5Ymoav0nNWQ > > ... So even if new devs like their own editors or so, they can see how > others manage it. > > - Campbell > >> Teika (Teika kazura) >> >> -- >> Sawfish ML >> > > > > > -- > - Campbell -- - Campbell -- Sawfish ML
