[m-rev.] for review: Use a better algorithm for unwinding version_arrays.

[Paul Bone]

On Tue, Sep 09, 2014 at 04:04:16PM +1000, Julien Fischer wrote:
>>>>
>>>> Would anyone object to me putting MercuryBitmap at
>>>> library/csharp/MercuryBitmap.cs and adding it to MLOBJS here?
>>>
>>> Yes, I object.  If we are going to end up with multiple C# modules
>>> forming part of the runtime / stdlib then they should be separated out
>>> as per the Java backend.  Relying on developers to always update the
>>> assignment to MLOBJS is very brittle.
>>
>> What's the difference between having to add an extra line to a Makefile or
>> an :- import_module directive in a .m file?
>
> I don't understand what you're trying to ask with that question.
>

It's rhetorical.  If you object to needing to list .cs files we want to link
against in MLOBJS then I'm inferring that you must also object to listing
compilation units of any kind when you're normally required to, like when
you import a module into your code.

>> Since we use GNU make we could also avoid this totally by saying:
>>
>>    MLOBJS += ../runtime/mercury_dotnet.cs $(wildcard csharp/*.cs)
>
> If you're going to do that you might as well build the C# version of the
> runtime as a separate assembly (much as we build a separate .jar file
> for Java backend.)

I have no problem with that.

> Also, under your scheme we now have (non-generated) C# source files
> scattered through multiple directories.

Ideally they should all be in one place.  Like we do for Java files.

>>>> Other shared code that's not exactly runtime code could go into the same
>>>> location.
>>>>
>>>> It seems to me that MercuryBitmap isn't runtime code because not all/most
>>>> modules need it.
>>>
>>> The bitmap code for C backends lives in runtime/mercury_bitmap.[ch]; I
>>> don't see that this situation is any different.  Just put it in
>>> runtime/mercury_dotnet.cs.
>>>
>>
>> Putting all the code in one file doesn't seem right to me.  MercuryBitmap
>> doesn't call code in mercury_dotnet.cs, or vice-versa.  This is why I'd
>> prefer seperate files.
>
> Most of the code in mercury_dotnet.cs doesn't call other code in that
> file.  The contents of that file are for the use of the standard library /
> generated code.  I agree it would be cleaner to have it an separate
> file, but things are not currently set up in such a way that will work.
>

Okay, we're confusing principals with what's practical right now.  I'm saying
we _should_ do something and I misunderstand when you say that we currently
can't do something like that without investing time to make it possible.

I'm currently testing my change with Peter's patch, if it works I'll commit
it.  This leaves MercuryBitmap in bitmap.m which seems to be the best
solution _for now_.

Cheers.


-- 
Paul Bone