If we have to move away from the makefiles (which have always worked quite well for me), then my vote is definitely for CMake.
Mike On Friday 20 April 2007 12:57:14 Cesc wrote: > Hi, > > Sounds all great, but that is really a lot work (it ain't bad, just > making an observation). > The libparser thing for example may mean having to adjust all modules ... > The autotoolize thing it was discussed just a few days ago without > much support ... but I am for it if you/someone needs to go for it (i > am still dreaming of an winOpenSer ;) ). My proposal would be, if you > are really serious, to let you commit the new build system and > co-exist with the Makefiles for a while ... People need a transition > period to start loving it ... if that does not happen, the new build > system gets removed ... > > Regards, > > Cesc > > On 4/20/07, Sebastien Tricaud <[EMAIL PROTECTED]> wrote: > > Hello people, > > > > > > following the IRC meeting, Bodgan asked me to write my thoughts here. > > > > > > * Current situation: > > OpenSER is modular, the code is separated in several directories for > > functions > > such as memory management, sip parsing, mi and other stuff... > > > > Its current architecture looks like (read bottom-top): > > > > [ higher level operations ] > > [ parser ] [ mi ] > > [ base : memory ] > > > > > > * What I would like to do: > > - Make sure each component is usable individually: I would like to > > use a high performance SIP parser. The OpenSER one fills the room. I am > > sure this is one way to have this library having more users, which mean > > used in ways OpenSER could not imagine, leading to discovering > > new bugs > > and have OpenSER avoid SIP parsing troubles [1]. > > - Maybe replace useless(!) things like memory management, which is > > what most > > C-written projects do. I think the base library could be Apache > > libAPR [2]. Maybe this is not the best choice, and if you have a > > better > > idea please let me know. > > > > > > * How I would like to do it: > > --> Submit patches :-) (put my money where my mouth is) > > - #1: Get rid of current Makefiles and use a build system > > (autotools/CMake?) > > - #2: Concatenating the actual memory management functions in a > > separate > > library 'libopenserbase' > > - #3: Put all SIP parser functions in a library 'libsipparser' > > - #4: (after a release I guess) Replace memory management functions > > using > > a third party library > > > > > > * When?: > > - I know patch #1 will be source of troubles, please let's be > > efficient. > > Unless you have a good argument, I would like to autotoolize > > OpenSER. > > - As Soon As Possible - > > - Patch #2 will come shortly after Patch #1, wait two weeks for > > feedback, > > then move to #3. > > - For Patch #4, I think we should carefully chose a library that has > > a good license and _fits_ OpenSER requirements. > > > > > > > > [1] http://labs.musecurity.com/advisories/MU-200703-01.txt > > [2] http://apr.apache.org/ > > > > > > > > Thank you very much for reading, feedback very welcome, > > > > Sebastien Tricaud. > > > > > > _______________________________________________ > > Devel mailing list > > Devel@openser.org > > http://openser.org/cgi-bin/mailman/listinfo/devel > > _______________________________________________ > Devel mailing list > Devel@openser.org > http://openser.org/cgi-bin/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
