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
