[MonoDevelop] CSharpCompilerParameters and CSharpProjectParameters
Michael Hutchinson
m.j.hutchinson at gmail.com
Mon Jun 14 11:42:12 EDT 2010
On Mon, Jun 14, 2010 at 1:02 AM, Vasili I. Galchin <vigalchin at gmail.com> wrote:
> Hi Michael,
>
> I am reviewing some of previous emails that I exchanged with you.
>
> 1) I am assuming that your interleaves below always refer to what is above them?
Correct :)
> 2) Please see my new interleaves below.
>
>
> Kind regards,
>
> Vasili
>
> On 4/9/10, Michael Hutchinson <m.j.hutchinson at gmail.com> wrote:
>> On Thu, Apr 8, 2010 at 11:09 PM, Vasili I. Galchin <vigalchin at gmail.com>
>> wrote:
>>> To put my question another way, of all "fsc --help" CLI parms which
>>> make sense to support in MonoDevelop F# support:
>>>
>>> - OUTPUT FILES -
>>> --out:<file> Name of the output file (Short form: -o)
>>> --target:exe Build a console executable
>>> --target:winexe Build a Windows executable
>>> --target:library Build a library (Short form: -a)
>>> --target:module Build a module that can be added to another
>>> assembly
>>> --delaysign[+|-] Delay-sign the assembly using only the
>>> public
>>> portion of the strong name key
>>> --doc:<file> Write the xmldoc of the assembly to the
>>> given
>>> file
>>> --keyfile:<file> Specify a strong name key file
>>> --keycontainer:<string> Specify a strong name key container
>>> --platform:<string> Limit which platforms this code can run on:
>>> x86,
>>> Itanium, x64 or anycpu. The default is
>>> anycpu.
>>
>> The C# binding has all of these. Most of them are generic .NET project
>> settings, not language-specific.
> ^^^ Michael, based
> ohttp://www.timesonline.co.uk/tol/news/world/middle_east/article7148555.ecen
> what your above interleave says ... options are not specfific to C#
> but instead "not language-specific" then why are these options not
> moved up and out of CSharpBindingCompilerManager.cs?? Please replicate
> this question to anywhere below where you also seem to say that the
> options are language-independent. Thanks.
Because no-one's done the work to do so. In many case, it's probably
not worth the effort, because they're trivial to implement, and might
not apply exactly the same way to every compiler. Perhaps they could
be abstracted out later.
--
Michael Hutchinson
http://mjhutchinson.com
More information about the Monodevelop-list
mailing list