[Asterisk-Dev] build/make environment

[Dr. Rich Murphey]

I'd be glad to modify whatever I've written to support FreeBSD in order to
take advantage of autoconf.   I believe autoconf would make support for *BSD
easier to achieve and easier to maintain.

Just count on me to modify it accordingly if autoconf is integrated.
Although I'd prefer to use autoconf, I suspect that the asterisk community
prefers work that is integrated into the distribution, so I'm focusing on
what's in CVS head.

Which begs some additional questions...

A practical issue for these features seems to be the stability of
enhancements - there should be no impact on linux stability and performance.
It's virtually necessary to use version control to stabilize the code
through iterative testing, but also necessary to do so outside of the
asterisk CVS in order to avoid impact on testing of the CVS head on linux.
Add to this the need for collaborative development and we have some tricky
choices with regard to the goal of integrating work into the asterisk CVS.

Cheers,
Rich

> -----Original Message-----
> From: asterisk-dev-admin at lists.digium.com [mailto:asterisk-dev-
> admin at lists.digium.com] On Behalf Of Theo Zourzouvillys
> Sent: Friday, May 21, 2004 11:23 PM
> To: asterisk-dev at lists.digium.com
> Subject: Re: [Asterisk-Dev] build/make environment
> 
> On Friday 21 May 2004 20:10, Tilghman Lesher wrote:
> > Congratulations.  You're the new maintainer of the autoconf option.
> > And before we hand you the title officially, we need a guarantee that
> > you'll be around for the next 3 years.  In case of death (your own),
> > we expect at least a 90 day advance notice, so we can make plans
> > to gut it or find a replacement maintainer.
> 
> I have and autoconf version based on asterisk cvs head here - and its
> pointless with the code the way it is - there are no more advantages to it
> than the current makefile system.
> 
> i totally agree with bk that the source tree needs a change around [1].
> all
> projects that start out small at some point need a major re-work of
> 'structure' from an administrative (not code) build system point of view,
> and
> it is a hugggge task initially, but well worth it in the long run, not
> only
> for the maintainers of the code, but more importantly for developers and
> porters.
> 
> a sensible directory structure, along with a roadmap (any maybe some rough
> dates would be good?) of which direction the code is heading, and if the
> maintainers want or give a shit about it compiling on anything other than
> linux/x86 are probably the best places to start.
> 
> wrt a structure, my first thoughts would be somethign like this:
> 
> |-- build
> |-- doc
> |-- support
> |-- core
> |   `-- arch
> |-- libs
> |   `-- stdtime
> `-- modules
>     |-- apps
>     |   |-- adsiprog
>     |   |-- echo
>     |   `-- enumlookup
>     |-- channels
>     |   |-- agent
>     |   `-- zap
>     |-- codecs
>     |   |-- a_mu
>     |   |-- adpcm
>     |   `-- ulaw
>     |-- pbx
>     |   |-- config
>     |   |-- spool
>     |   `-- willcallu
>     `-- res
>         |-- adsi
>         |-- config
>         |   |-- ini
>         |   |-- perl
>         |   `-- db
>         |-- musiconhold
>         `-- parking
> 
> all the *core* of asterisk should move into it's own directory, leaving
> the
> top directory fairly empty (somethign most people seem to like) other than
> a
> README, ./configure(.in), and few other misc files, all the build scripts
> and
> autoconf/make/header stuff should go into build/.
> 
> each module subdirectry should contain a directory for *each* module,
> which
> means people can split the bigger modules down into logical blocks, so you
> don't end up with files 4k+ in length which makes finding somethign you
> want
> pretty hard.
> 
> i'd question why libeditline and berkeleydb are in cvs at all?
> 
> some form of asterisk-config (or maybe just use pkg-config) tool should
> also
> be installed, which takes --cflags, --version and --libs to make it easy
> to
> add modules in that are outside of digiums source tree, somethign
> currently
> not the easiest of things.
> 
> headers should be installed, too.
> 
> all the paths curently -D'ed to gcc should move into an asterisk/paths.h
> or
> some form, but, thinking about it, why the hell are there any hard coded
> paths other than the *default* config file??
> 
> People, i think we need to take a stand back, and look what the hell we're
> buulding here - a makeshift shanty house, which keeps the rain off our
> head,
> or a nice shiny new house, built from the gound up well?  code seems to be
> added and added, and just 'hacked' in place - no real design or API's,
> cetianly nothing people like me could reference in a document/mailing list
> post somewhere.
> 
> and thats the only reason i'm not spending 4 hours+ a day doign things on
> asterisk (where's the todo list for people like me to work on when bored
> for
> a few hours/days?) - i can see a million thigns that would make life a lot
> easier for both users and developers from both a code and concept point of
> view.
> 
> i can sadly see a zebra/quagga situation starting to brew here.
> 
>  ~ Theo
> 
> 1 - Change - We all hate that right?
> 
> --
> Theo Zourzouvillys
> theo at crazygreek.co.uk
> http://www.crazygreek.co.uk/
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev