Officially supported Development Tool Set

Forum thread started by Octopus on Sun, 2010-12-19 21:34

There a lot of coming gimmicks and functional improvements currently are requested and being built.

But before the motivation will widely grow to put a lot of time and efforts into the writing of generic applications for Haiku there is a need to officially identify a set of prioritized development tools as to be supported for several years. It is not attractive to have the risk to waist ones time. No one is bound to make developments especially using Haiku. Writing for Haiku using C++ should be attractive and not in vain. Because of the programmers' world is full of OS alternatives.

Comments

Re: Officially supported Development Tool Set

I'm not sure what you mean by gimmicks? As for attracting developers, in my opinion the most important thing is to have a good API to work against, and here Haiku shines (imo). Particularly since it encompasses a huge amount of functionality through it's array of kits and also because the API is very consistent. As for 'development tool set', there's 'Paladin' as an IDE (or good old Pe if you are feeling nostalgic), there's also work on a new native debugger to replace gdb afaik.

Re: Officially supported Development Tool Set

Rox wrote:

... there's ...

Of course there are some tools. But the point is, neither a decision on a preferred compiler / library is made nor an official recommendation for a landscape of tools exits. Thus e.g. I am preceding with waiting instead of using Haiku for programming.

Re: Officially supported Development Tool Set

Paladin is good, but the thing I miss a lot in it is a Gui Builder, its more simple to "disegnate" the GUI and press "Create Code" that do weird x,y calculations...

This is an option that can attire those habituated to use Visual Studio... the code is most written for you -:)

Re: Officially supported Development Tool Set

Octopus wrote:

neither a decision on a preferred compiler / library is made nor an official recommendation for a landscape of tools exits.

Well, as for compilers there's only GCC and Clang/llvm and since Clang aims to be a drop in replacement for GCC you will be able to use them interchangeably so I fail to see what the problem is? What do you mean by library? Haiku has a official API consisting of an array of 'kits'.

Re: Officially supported Development Tool Set

Octopus wrote:

Of course there are some tools. But the point is, neither a decision on a preferred compiler / library is made nor an official recommendation for a landscape of tools exits. Thus e.g. I am preceding with waiting instead of using Haiku for programming.

gcc is the official compiler with both gcc 2 and 4 being officially supported. The other standard-issue development tools found under Linux, such as flex, bison, etc. are also in use. jam is the build tool for the source tree and (obviously) is supported.

You will be hard-pressed to find an official recommendation for a development environment, however. The main reason is that at least the core developers are a "live and let live" kind of bunch who don't really care what others use for development tools so long as it gets the job done. I would say that if there were an officially sanctioned tool by the core developers, it would be Pe. Quite a few of them use it. While I don't contribute anywhere near as much code as I used to, I'm also one of the Haiku developers and also the author of the Paladin IDE. It's all I use for Haiku development except for when I'm hacking on the Haiku source tree.

fano wrote:

Paladin is good, but the thing I miss a lot in it is a Gui Builder, its more simple to "disegnate" the GUI and press "Create Code" that do weird x,y calculations...

This is an option that can attire those habituated to use Visual Studio... the code is most written for you -:)

I've got one in development called PDesigner. Unlike VS, the window and controls are live. The component system that I'm using to create it will also pave the way for creating GUI apps for Haiku without using C++ or yab. It's still a long ways off because there is no code generation yet, but there's work being done at least.