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

[Yaacov Akiba Slama]

Hello,

The hack you proposed doesn't work because in general, there is no one
to one mapping between .jvm files and regular mono files. You can see
for instance System.Data.dll where the java connected mode is completely
different than the mono one.

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) net_1_1 needs A and B
2) net_2_2 needs A, B and C
3) java_net_1_1 needs A and D

We need to have four files :

common.sources contains :
A

net_1_1.sources :
#include common
B

net_2_0.sources:
#includes net_1_1
C

java_net_1_1.sources:
#includes common
D

The xml file Ynon proposed was only the reunion of all these file.

In summary, we have at least the following possibilities :

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.

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

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.

4) Use one xml file containing the whole information
Advantages: one single and simple file containg all the information.
Disadvantages: XML is overkill ; cannot use sort | uniq like operations

5) Use a single in another format (.ini file for instance).
Advantages: the same as 4)
Disadvantages: cannot use sort | uniq like operations.

What do you think ?

Thanks,

--yas

Ben Maurer wrote:

>>Hi,  Kornél.
>>
>>The .jvm.cs are part of the Java build that we are now doing from svn
>>using make.
>>The issue is not limited to the .jvm files but also to Mono sources
>>(e.g. in System.Web) that are not part of the Java build. In System.Web
>>we have about 30 Mono files that we don't compile in the Java build
>>(because we don't support yet on the fly compilation of .aspx files and
>>CodeDom).
>>So in our case we have more files that belong to specific profiles or
>>combinations of profiles.
>>Personally, the issue here is the number of profiles and their
>>complexity. The more profiles are used the more useful the proposed
>>change is. If everyone believes that there are not going to be more
>>profiles then the Java profile then there is less incentive to change
>>anything - the current solution of ifdefs is still usable.
>>    
>>
>
>I don't see anyone adding another profile other than NET_2_1 or whatever.
>
>What if there was a hack where blah.jvm.cs files are only compiled for the
>jvm target and blah.cs is not compiled in the jvm target if blah.jvm.cs
>exists?
>
>That way the sources file stays the same (allowing us to echo FILENAME >
>blah.sources and use sort | uniq).
>
>-- Ben
>  
>