[Mono-dev] [PATCH] Source list per profile
Raja R Harinath
rharinath at novell.com
Fri Aug 19 03:12:17 EDT 2005
Yaacov Akiba Slama <yaslama at mainsoft.com> writes:
> The problem with separate source files per profile is the redundancy :
> when someone adds a file he needs to add it to several .sources.
> One way to handle with this problem is to add an "include" feature in
> the .sources files. But the price to pay (if we don't want redundancy)
> is the multiplication of files. For instance let's suppose that :
> 1) Use on .sources file only and enclose the content of each file not
> used by _every_ profile by #ifdef.
> Advantages: Only one single .sources
> Disadvantages: A lot of #ifdefs in a large part of the files.
The current approach. I don't see the #ifdef as being a problem, since
it encloses the whole file, and is otherwise reasonably unobstrusive.
> 2) Use one .sources per profile with redundancy.
> Advantages: clear separation between each profile.
> Disadvantages: Needs to syncronize manually between profiles each time a
> new file is added (or a file is removed).
Yep. Not a good idea.
> 3) Use one file per profile using includes.
> Advantages: can use sort | uniq operations. Simple format.
> Disadvantages: more files that the # of profiles if we don't want
No need for includes. We can do a hybrid approach. The usual
file has all the sources that are common to all profiles. Sources that
belong to only one profile (say net_2_0) will be listed in
Sources that belong to multiple profiles (but not all) will be listed in
the common foo.dll.sources file, and the actual source files will have
In all, however, I feel the current approach is quite nice, since it
documents, in the source file itself, which API is being used in that
file. My only reason for contemplating per-profile additional response
files is to make build dependencies more precise.
More information about the Mono-devel-list