[m-rev.] diff: fix MC++ compilation rule

[Fergus Henderson]

On 20-Nov-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> fjh wrote:
> > scripts/Mmake.rules:
> > compiler/compile_target_code.m:
> >	Be consistent about using `-' rather than `/' for options to cl.
> >	Use `-o ' rather than `-link -out:'.
> >	Ensure that `-o' comes before $(MS_CL_LIBS).
> >	Resynchronize the release branch with the main branch.
> >
> This diff looks great.

and then

> fjh wrote:
> 
> > On 05-Nov-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> > > Fix a bug in my previous change to fix a bug in fjh's previous change.
> > > Revert back to using '/out:', and instead add the flag '/link' so that
> '/out:'
> > > is passed to the linker instead to avoid problems compiling the library.
> >
> > That's not going to work, I'm pretty sure.  See MS_CL_LIBS in
> > library/Mmakefile.  You'll end up passing "/link /out:... /link ..."
> > when building the library in the il grade, and then the linker will complain
> > that "/link" is not a valid option.
>
> It complains, but it is just a warning, not an error.
> 
> > What was wrong with the original approach of using `/o' (or was it `-o'?)?
>
> The former rule for building IL files is
> 
> $(os_subdir)%.dll : %.cpp
>         $(MS_CL) -CLR$(MS_CL_NOASM) $(ALL_MS_CLFLAGS) \
>                 -I`$(FIX_PATH_FOR_CL) $(MERC_C_INCL_DIR)` \
>                 -AI`$(FIX_PATH_FOR_CL) $(MERC_DLL_DIR)` $< \
>                 /LD $(MS_CL_LIBS) -o:$@
>         rm -f $*.obj
> 
> MS_CL_LIBS comes before -o:$@ and so the line in library/Mmakefile means
> that -o is now passed to the linker and it fails.

Yes, that much I had figured out.

> There are three possible
> fixes at this point.
>     * Add /link before $(MS_CL_LIBS) and change back to -out:$@
>     * Move the -o:$@ before MS_CL_LIBS
>     * Add a new variable MS_LINKER_ARGS and refer to that in
> library/Mmakefile
> 
> I choose the first one because it is the closest to what happened previously
> and hence the least likely to cause problems in other peoples Mmakefiles.

OK.  I don't think backwards compatibility is important for the .NET
back-end at this point.  But I would be happy with any of these solutions.

I will commit the diff that I posted because, well, because that one is
already done and any of the others would require more work.  (The first
alternative is already done too, but to use that I'd have to redo the
work for the other parts of my diff:

	Be consistent about using `-' rather than `/' for options to cl.
	Resynchronize the release branch with the main branch.)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------