[Asterisk-Dev] build/make environment

[Theo Zourzouvillys]

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/