Re: Building Sawfish (was: Re: [Sawfish] lack of contributors)

[Campbell Barton <ideasman42@xxxxxxxxx>]

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 <ideasman42@xxxxxxxxx> wrote:
> On Thu, Apr 5, 2012 at 4:57 PM, Teika Kazura <teika@xxxxxxxxxxx> 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