On Wed, 16 Apr 2008, Danny Backx wrote:
> I'd like to figure out how to get all this organised and streamlined > before we actually start. > > Here are some suggestions, please all comment so we can agree on > something that works for all : > 1. Generic stuff > a) All submissions should be ports of a software that falls under some > free software license. I agree. Maybe we can list some that are really important. I have a list, btw ;) > b) A minimal submission is a source port. A compiled version is optional > but desirable. compile must separate binaries (dll + executables) from development (headers + static and import lib, maybe .def). some packages maybe require some dependencies. Like the binaries built in libjpeg, which depend on librle (the lib of libjpeg does not depend on the bin) In the GnuWin32 packages, the diff is also provided, in addition to other files like one which lists the files of the packages, for example > c) Submissions must be accompanied by a document which describes the > port. We'll design a template for that. ok > d) Compiled versions should use a standard set of compiler and configure > options : > PREFIX=/opt/wince > CFLAGS="-D_WIN32_WCE=0x0400 -D_WIN32_IE=0x0400" this should go into CPPFLAGS. Also should we add -mms-bitfields in CFLAGS ? For executables, should we add -mwindows ? Same for optimization flags, like the -O* or -mcpu or -march ? > 2. Template > a) the license of the software > b) the URL from which to download the original version > c) the version of the software from which this port is derived c') the needed dependencies and their minimal version ? > d) the maintainer of this port > e) a source patch > f) the version of cegcc that this is compiled with > (version number + architecture: e.g. arm-mingw32ce) maybe the optimization flags ? -O2 or -O3 or -Os, -mcpu, -march ? > f) (optionally) description of porting issues > g) (optionally) file name of full source (patched) > h) (optionally) file name of binary version file name of development version ? of dependency version ? > The filled out template could go in the release notes in the SF file and > release mechanism. > > 3. Stuff derived from working with the SourceForge file and release > system. > a) for practical reasons, a limited set of people is currently capable > of accessing the SourceForge cegcc site, they are a filter. > b) Submissions must be uploaded in agreement with one of the people > outlined above, knowing that the SF upload facility keeps files for a > limited amount of time, so be prepared to upload again if the agreement > is not clear enough and nobody had the time to pick up your files before > SF expired them. I don't have comments here. regards Vincent Torri ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
