[Mono-dev] [PATCH] Source list per profile

[Raja R Harinath]

Hi,

Yaacov Akiba Slama <yaslama at mainsoft.com> writes:
[snip]
> 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 :
[snip]

> 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
> duplicates.

No need for includes.  We can do a hybrid approach.  The usual

  foo.dll.sources

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

  foo.dll.net_2_0.sources

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
#ifdef guards.

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.

- Hari