[Mono-bugs] [Bug 36410][Wis] New - mcs should accept options intermixed with source files
bugzilla-daemon@rocky.ximian.com
bugzilla-daemon@rocky.ximian.com
Tue, 7 Jan 2003 18:05:59 -0500 (EST)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by jonpryor@vt.edu.
http://bugzilla.ximian.com/show_bug.cgi?id=36410
--- shadow/36410 Tue Jan 7 18:05:58 2003
+++ shadow/36410.tmp.17699 Tue Jan 7 18:05:58 2003
@@ -0,0 +1,57 @@
+Bug#: 36410
+Product: Mono/MCS
+Version: unspecified
+OS: other
+OS Details:
+Status: NEW
+Resolution:
+Severity:
+Priority: Wishlist
+Component: Misc
+AssignedTo: mono-bugs@ximian.com
+ReportedBy: jonpryor@vt.edu
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL:
+Cc:
+Summary: mcs should accept options intermixed with source files
+
+Please fill in this template when reporting a bug, unless you know what you
+are doing.
+Description of Problem:
+
+This is a wishlist item, though csc.exe also behaves the way I describe here.
+
+I want to be able to have mcs program arguments intermixed with the listing
+of source files, not require that they be first.
+
+For example, with ``mcs -v myfile.cs'' I get verbose parsing, but with
+``mcs myfile.cs -v'' (notice that `-v' was moved after the file name) I
+don't get verbose output.
+
+I know that this also affects the `-d' (--define) option, but not other
+options (such as -r, -L, etc.). Looking at the mcs source, I'm not sure
+why this is the case; otherwise, I'd fix it myself.
+
+I ran into this because I want to have two makefile targets, the contents
+of which are nearly identical, e.g.
+
+ console:
+ $(CSC) $(COMMON_OPTIONS) $(FILES)
+
+ gui:
+ $(CSC) $(COMMON_OPTIONS) $(GUI_OPTIONS) $(FILES)
+
+Ideally, I'd have this:
+
+ CSC_INVOKE = $(CSC) $(COMMON_OPTIONS) $(FILES)
+
+ console:
+ $(CSC_INVOKE)
+
+ gui:
+ $(CSC_INVOKE) $(GUI_OPTIONS)
+
+This simplifies maintenance. However, this doesn't work if $(GUI_OPTIONS)
+contains defines (-d), as mcs ignores them. This prevents the second
+makefile from working as expected.