vim7: Make_mvc.mak

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

vim7: Make_mvc.mak

Walter Briscoe
I merged Bram's latest Make_mvc.mak with my own. I have suggestions:

1) +CPPFLAGS = $(CFLAGS)
$(OBJDIR)/*.obj are implicitly built from ./*.c and ./*.cpp.
It is possible to explicitly build ./*.obj from ./*.c with calls such as
nmake -nologo -f Make_mvc.mak main.obj. The new line allows lines like
nmake -nologo -f Make_mvc.mak if_ole.obj. to build in . with *.cpp.


2) Replace $(VIM) target with $(VIM).exe. Otherwise, $(VIM) is always
out of date.


3)
-iid_ole.c if_ole.h vim.tlb: if_ole.idl $(INTDIR) $(OUTDIR)
-       midl /nologo /proxy nul /iid iid_ole.c /tlb vim.tlb /header if_ole.h if_ole.idl
+iid_ole.c if_ole.h dlldata.c vim.tlb: if_ole.idl
+       midl /nologo /error none /proxy nul /iid iid_ole.c /tlb vim.tlb /header if_ole.h if_ole.idl

As the midl call builds files in the current directory, the dependencies
on $(INTDIR) and $(OUTDIR) are not necessary.
The list of files built is incomplete.
Bram supplies versions of the output files built with VC5 which defaults
to /error none. VC6 (and later?) default to /error all.
Relying on the variable default seems inappropriate.
(I would also be happy with /error all and a new set of outputs. I just
want things to be consistent.)
(The outputs of dimm.idl are not delivered. It is probably better to
use an explicit /error option also with dimm.idl. Putting outputs in the
current directory rather than $(OBJDIR) seems inconsistent.)

Here is the patch:

--- src/Make_mvc.mak.0  Sun Jul  3 10:45:06 2005
+++ src/Make_mvc.mak    Sun Jul  3 15:34:22 2005
@@ -656,6 +656,7 @@
 # on a crash (doesn't add overhead to the executable).
 #
 CFLAGS = $(CFLAGS) /Zi
+CPPFLAGS = $(CFLAGS)
 PDB = /Fd$(OUTDIR)/
 LINK_PDB = /PDB:$(OUTDIR)/$(VIM).pdb -debug:full -debugtype:cv,fixup

@@ -679,17 +680,15 @@
                $(MZSCHEME_LIB) $(PERL_LIB) $(PYTHON_LIB) $(RUBY_LIB) $(TCL_LIB) \
                $(NETBEANS_LIB) $(XPM_LIB) $(LINK_PDB)

-all:   $(VIM) vimrun.exe install.exe uninstal.exe xxd/xxd.exe GvimExt/gvimext.dll
+all:   $(VIM).exe vimrun.exe install.exe uninstal.exe xxd/xxd.exe GvimExt/gvimext.dll

-$(VIM): $(OUTDIR) $(OBJ) $(GUI_OBJ) $(OLE_OBJ) $(OLE_IDL) $(MZSCHEME_OBJ) $(PERL_OBJ) $(PYTHON_OBJ) $(RUBY_OBJ) $(TCL_OBJ) $(SNIFF_OBJ)
$(CSCOPE_OBJ) $(NETBEANS_OBJ) $(XPM_OBJ) version.c version.h
-       $(CC) $(CFLAGS)  version.c /Fo$(OUTDIR)/version.obj $(PDB)
+$(VIM).exe: $(OUTDIR) $(OBJ) $(GUI_OBJ) $(OLE_OBJ) $(OLE_IDL) $(MZSCHEME_OBJ) $(PERL_OBJ) $(PYTHON_OBJ) $(RUBY_OBJ) $(TCL_OBJ) $(SNIFF_OBJ)
$(CSCOPE_OBJ) $(NETBEANS_OBJ) $(XPM_OBJ) version.c version.h
+       $(CC) $(CFLAGS) /Fo$(OUTDIR)/ $(PDB) version.c
        $(link) $(LINKARGS1) -out:$*.exe $(OBJ) $(GUI_OBJ) $(OLE_OBJ) \
                $(MZSCHEME_OBJ) $(PERL_OBJ) $(PYTHON_OBJ) $(RUBY_OBJ) $(TCL_OBJ) $(SNIFF_OBJ) \
                $(CSCOPE_OBJ) $(NETBEANS_OBJ) $(XPM_OBJ) \
                $(OUTDIR)\version.obj $(LINKARGS2)

-$(VIM).exe: $(VIM)
-
 $(OUTDIR):
        if not exist $(OUTDIR)/nul  mkdir $(OUTDIR)

@@ -907,8 +906,8 @@
 $(OUTDIR)/vim.res:     $(OUTDIR) vim.rc version.h tools.bmp tearoff.bmp vim.ico vim_error.ico vim_alert.ico vim_info.ico vim_quest.ico
        $(RC) /l 0x409 /Fo$(OUTDIR)/vim.res $(RCFLAGS) vim.rc

-iid_ole.c if_ole.h vim.tlb: if_ole.idl $(INTDIR) $(OUTDIR)
-       midl /nologo /proxy nul /iid iid_ole.c /tlb vim.tlb /header if_ole.h if_ole.idl
+iid_ole.c if_ole.h dlldata.c vim.tlb: if_ole.idl
+       midl /nologo /error none /proxy nul /iid iid_ole.c /tlb vim.tlb /header if_ole.h if_ole.idl

 dimm.h dimm_i.c: dimm.idl
        midl /nologo /proxy nul dimm.idl

--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: vim7: Make_mvc.mak

Bram Moolenaar

Walter Briscoe wrote:

> I merged Bram's latest Make_mvc.mak with my own. I have suggestions:
>
> 1) +CPPFLAGS = $(CFLAGS)
> $(OBJDIR)/*.obj are implicitly built from ./*.c and ./*.cpp.
> It is possible to explicitly build ./*.obj from ./*.c with calls such as
> nmake -nologo -f Make_mvc.mak main.obj. The new line allows lines like
> nmake -nologo -f Make_mvc.mak if_ole.obj. to build in . with *.cpp.

$(CPPFLAGS) is not used.  the .cpp.obj rule uses $(CFLAGS).

> 2) Replace $(VIM) target with $(VIM).exe. Otherwise, $(VIM) is always
> out of date.

OK, but then also change the dependency:

        $(VIM).exe: $(VIM)
to:
        $(VIM): $(VIM).exe

And change the -out argument not to generate vim.exe.exe!

> 3)
> -iid_ole.c if_ole.h vim.tlb: if_ole.idl $(INTDIR) $(OUTDIR)
> -       midl /nologo /proxy nul /iid iid_ole.c /tlb vim.tlb /header if_ole.h if_ole.idl
> +iid_ole.c if_ole.h dlldata.c vim.tlb: if_ole.idl
> +       midl /nologo /error none /proxy nul /iid iid_ole.c /tlb vim.tlb /header if_ole.h if_ole.idl
>
> As the midl call builds files in the current directory, the dependencies
> on $(INTDIR) and $(OUTDIR) are not necessary.

OK.

> The list of files built is incomplete.

That is not relevant, if one is outdated they are all rebuild.

> Bram supplies versions of the output files built with VC5 which defaults
> to /error none. VC6 (and later?) default to /error all.

What does this argument do?


--
hundred-and-one symptoms of being an internet addict:
217. Your sex life has drastically improved...so what if it's only cyber-sex!

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: Make_mvc.mak

Walter Briscoe
In message <[hidden email]> of Sun, 3 Jul
2005 20:05:17 in , Bram Moolenaar <[hidden email]> writes

>
>Walter Briscoe wrote:
>
>> I merged Bram's latest Make_mvc.mak with my own. I have suggestions:
>>
>> 1) +CPPFLAGS = $(CFLAGS)
>> $(OBJDIR)/*.obj are implicitly built from ./*.c and ./*.cpp.
>> It is possible to explicitly build ./*.obj from ./*.c with calls such as
>> nmake -nologo -f Make_mvc.mak main.obj. The new line allows lines like
>> nmake -nologo -f Make_mvc.mak if_ole.obj. to build in . with *.cpp.
>
>$(CPPFLAGS) is not used.  the .cpp.obj rule uses $(CFLAGS).
The default      rule for .c.obj   uses CFLAGS
The default      rule for .cpp.obj uses CPPFLAGS
The Make_mvc.mak rule for .c.obj uses CFLAGS
The Make_mvc.mak rule for .cpp.obj uses CFLAGS

Equating CPPFLAGS to $(CFLAGS) sorts things out.
May be better to equate and use CPPFLAGS in Make_mvc.mak .cpp.obj rule.

>
>> 2) Replace $(VIM) target with $(VIM).exe. Otherwise, $(VIM) is always
>> out of date.
>
>OK, but then also change the dependency:
>
>       $(VIM).exe: $(VIM)
>to:
>       $(VIM): $(VIM).exe
>
>And change the -out argument not to generate vim.exe.exe!

Did I do that?
In building $(VIM).exe, I used -out:$*.exe.
I find, in MSDN (had to check):
$* Current target's path and base name minus file extension.
Looks OK to me.

>
>> 3)
>> -iid_ole.c if_ole.h vim.tlb: if_ole.idl $(INTDIR) $(OUTDIR)
>> -       midl /nologo /proxy nul /iid iid_ole.c /tlb vim.tlb /header
>>if_ole.h if_ole.idl
>> +iid_ole.c if_ole.h dlldata.c vim.tlb: if_ole.idl
>> +       midl /nologo /error none /proxy nul /iid iid_ole.c /tlb
>>vim.tlb /header if_ole.h if_ole.idl
>>
>> As the midl call builds files in the current directory, the dependencies
>> on $(INTDIR) and $(OUTDIR) are not necessary.
>
>OK.
>
>> The list of files built is incomplete.
>
>That is not relevant, if one is outdated they are all rebuild.
That may be OK.

>
>> Bram supplies versions of the output files built with VC5 which defaults
>> to /error none. VC6 (and later?) default to /error all.
>
>What does this argument do?
I thought you might ask that:

This is from MSDN,  mk:@MSITStore:D:\MSDN.DVD\MSDN\MIDL.chm::/hh/midl/mi-cmdln_5r1u.htm
I may have spare set of MSDN CDs. Can you use?

/error
The /error switch determines the types of error checking that the generated stubs will perform at run time.

Switch Options
midl /error { allocation | stub_data | ref | bounds_check | none | all }
allocation
Checks whether midl_user_allocate returns a NULL value, indicating an out-of-memory error.
stub_data
Generates a stub that catches unmarshaling exceptions on the server side and propagates them back to the client.
ref
Generates code that runs a check at run time to ensure that no NULL reference pointers are being passed to the client stubs and raises an
RPC_X_NULL_REF_POINTER exception if it finds any.
bounds_check
Checks size of conformant-varying and varying arrays against transmission length specification.
none
Performs no error checking.
all
Performs all error checking. Effective with MIDL version 5.0, this is a default compiler switch.
Remarks
The /error switch selects the number of error checks that the generated stub files will perform. Effective with MIDL version 5.0, the default
setting is /error all.

The enum errors that are checked (by default in all versions of MIDL) are truncation errors caused when converting between long enum types
(32-bit integers) and short enum types (the network-data representation of enum), and the number of identifiers in an enumeration exceeding
32,767.

The memory-access error checking (also by default in all versions of MIDL) is for pointers that exceed the end of the buffer in marshaling code
and for conformant arrays whose size is less than zero. Use the /ERROR BOUNDS_CHECK flag to check for other invalid array bounds.

When you specify /error allocate, the stubs include code that raises an exception when midl_user_allocate returns 0.

The /error stub_data option prevents client data from crashing the server during unmarshaling, effectively providing a more robust method of
handling the unmarshaling operation.

Effective with Windows 2000, the underlying run-time NDR marshaling engine performs most of these checks. This means that if you are using one
of the fully-interpreted modes (/Oi, /Oif) of stub generation, choosing different error checking options will not have a marked effect on
performance.

Examples
midl /error allocation filename.idl
midl /error none filename.idl
See Also
General MIDL Command-line Syntax, /robust
--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: vim7: Make_mvc.mak

Bram Moolenaar

Walter Briscoe wrote:

> >> I merged Bram's latest Make_mvc.mak with my own. I have suggestions:
> >>
> >> 1) +CPPFLAGS = $(CFLAGS)
> >> $(OBJDIR)/*.obj are implicitly built from ./*.c and ./*.cpp.
> >> It is possible to explicitly build ./*.obj from ./*.c with calls such as
> >> nmake -nologo -f Make_mvc.mak main.obj. The new line allows lines like
> >> nmake -nologo -f Make_mvc.mak if_ole.obj. to build in . with *.cpp.
> >
> >$(CPPFLAGS) is not used.  the .cpp.obj rule uses $(CFLAGS).
> The default      rule for .c.obj   uses CFLAGS
> The default      rule for .cpp.obj uses CPPFLAGS
> The Make_mvc.mak rule for .c.obj uses CFLAGS
> The Make_mvc.mak rule for .cpp.obj uses CFLAGS
>
> Equating CPPFLAGS to $(CFLAGS) sorts things out.
> May be better to equate and use CPPFLAGS in Make_mvc.mak .cpp.obj rule.

I don't get it.  The default rule is never used.  CPPFLAGS would always
be equal to CFLAGS.  I don't see a reason to change it.  Why look at the
default rule while we don't use it?

--
From the classified section of a city newspaper:
Dog for sale: eats anything and is fond of children.


 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: Make_mvc.mak

Dave Roberts
Bram Moolenaar wrote:

>Walter Briscoe wrote:
>
>  
>
>>>>I merged Bram's latest Make_mvc.mak with my own. I have suggestions:
>>>>
>>>>1) +CPPFLAGS = $(CFLAGS)
>>>>$(OBJDIR)/*.obj are implicitly built from ./*.c and ./*.cpp.
>>>>It is possible to explicitly build ./*.obj from ./*.c with calls such as
>>>>nmake -nologo -f Make_mvc.mak main.obj. The new line allows lines like
>>>>nmake -nologo -f Make_mvc.mak if_ole.obj. to build in . with *.cpp.
>>>>        
>>>>
>>>$(CPPFLAGS) is not used.  the .cpp.obj rule uses $(CFLAGS).
>>>      
>>>
>>The default      rule for .c.obj   uses CFLAGS
>>The default      rule for .cpp.obj uses CPPFLAGS
>>The Make_mvc.mak rule for .c.obj uses CFLAGS
>>The Make_mvc.mak rule for .cpp.obj uses CFLAGS
>>
>>Equating CPPFLAGS to $(CFLAGS) sorts things out.
>>May be better to equate and use CPPFLAGS in Make_mvc.mak .cpp.obj rule.
>>    
>>
>
>I don't get it.  The default rule is never used.  CPPFLAGS would always
>be equal to CFLAGS.  I don't see a reason to change it.  Why look at the
>default rule while we don't use it?
>
>  
>

After doing a 'cvs update' I find that revision 1.16 of Make_mvc.mak no
longer creates a VIM or GVIM executable when using Visual Studio.NET
2003. I get the following:

        cd xxd
        nmake /NOLOGO -f Make_mvc.mak
        cl /nologo -DWIN32 xxd.c /link setargv.obj
xxd.c
        cd ..
        cd GvimExt
        nmake /NOLOGO -f Makefile
        cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -D_X86_=1  
-DWIN32 -D_WIN32 -W3 -D_WIN32_IE=0x0400 -DWINVER=0x0400 -DFEAT_GETTEXT  
-D_MT -D_DLL -MD gvimext.cpp
gvimext.cpp
        Rc /r -DWIN32 -D_WIN32 -DWINVER=0x0400   gvimext.rc
        lib /NOLOGO -machine:i386 -def:gvimext.def gvimext.obj
gvimext.res -out:
gvimext.lib
gvimext.def(4) : warning LNK4017: DESCRIPTION statement not supported
for the target platform; ignored
   Creating library gvimext.lib and object gvimext.exp
        link  /INCREMENTAL:NO /NOLOGO -entry:_DllMainCRTStartup@12 -dll
-base:0x1C000000 -out:gvimext.dll gvimext.obj gvimext.res ole32.lib
uuid.lib oleaut32.lib kernel32.lib  ws2_32.lib mswsock.lib advapi32.lib
user32.lib gdi32.lib comdlg32.lib winspool.lib shell32.lib gvimext.lib
comctl32.lib gvimext.exp
        cd ..

(done)

*****************
By reverting to revision 1.15 I'm able to create the executables.

Thanks,

- Dave
Reply | Threaded
Open this post in threaded view
|

Re: vim7: Make_mvc.mak

Bram Moolenaar

Dave Roberts wrote:

> After doing a 'cvs update' I find that revision 1.16 of Make_mvc.mak no
> longer creates a VIM or GVIM executable when using Visual Studio.NET
> 2003. I get the following:

I shouldn't have removed .exe from the -out argument.  I'll fix it.

--
Get a life?  What is the URL where it can be downloaded?

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: Make_mvc.mak

Walter Briscoe
In reply to this post by Bram Moolenaar
In message <[hidden email]> of Mon, 4 Jul
2005 12:27:04 in , Bram Moolenaar <[hidden email]> writes

>
>Walter Briscoe wrote:
>
>> >> I merged Bram's latest Make_mvc.mak with my own. I have suggestions:
>> >>
>> >> 1) +CPPFLAGS = $(CFLAGS)
>> >> $(OBJDIR)/*.obj are implicitly built from ./*.c and ./*.cpp.
>> >> It is possible to explicitly build ./*.obj from ./*.c with calls such as
>> >> nmake -nologo -f Make_mvc.mak main.obj. The new line allows lines like
>> >> nmake -nologo -f Make_mvc.mak if_ole.obj. to build in . with *.cpp.
>> >
>> >$(CPPFLAGS) is not used.  the .cpp.obj rule uses $(CFLAGS).
>> The default      rule for .c.obj   uses CFLAGS
>> The default      rule for .cpp.obj uses CPPFLAGS
>> The Make_mvc.mak rule for .c.obj uses CFLAGS
>> The Make_mvc.mak rule for .cpp.obj uses CFLAGS
>>
>> Equating CPPFLAGS to $(CFLAGS) sorts things out.
>> May be better to equate and use CPPFLAGS in Make_mvc.mak .cpp.obj rule.
>
>I don't get it.  The default rule is never used.  CPPFLAGS would always
>be equal to CFLAGS.  I don't see a reason to change it.  Why look at the
>default rule while we don't use it?

Let me try again:
The default      rule for .c.obj   uses CFLAGS
The Make_mvc.mak rule for .c.obj uses CFLAGS
The default      rule for .cpp.obj uses CPPFLAGS
The Make_mvc.mak rule for .cpp.obj uses CFLAGS rather than CPPFLAGS.

So, I can get something sensible when I decide to do, for example,
nmake -nologo -f Make_mvc.mak buffer.obj

Unless we make some change, I do not get anything sensible when I try
nmake -nologo -f Make_mvc.mak if_ole.obj

The difference is that our coding changes the effect of the .c.obj
default rule but does not change the effect of the .cpp.obj rule.

I made this change several weeks ago so I could generate .i files.
The relevant extract from my script to do so is:
nmake -nologo -a -n -f %makefile% %1.obj | sed "/^$/d;s/  */ /g;s/$/ -P -C/" >> %tfile%
That sed script: identifies empty lines and deletes them; changes runs
of spaces to one space; and appends " -P -C" to the generated line.

That script already works if %1.obj is built from %1.c
The change allows working if %1.obj is built from %1.cpp

The change is for consistency in by-product abilities of Make_mvc.mak.
--
Walter Briscoe
Reply | Threaded
Open this post in threaded view
|

Re: vim7: Make_mvc.mak

Bram Moolenaar

Walter Briscoe wrote:

> Let me try again:
> The default      rule for .c.obj   uses CFLAGS
> The Make_mvc.mak rule for .c.obj uses CFLAGS
> The default      rule for .cpp.obj uses CPPFLAGS
> The Make_mvc.mak rule for .cpp.obj uses CFLAGS rather than CPPFLAGS.
>
> So, I can get something sensible when I decide to do, for example,
> nmake -nologo -f Make_mvc.mak buffer.obj
>
> Unless we make some change, I do not get anything sensible when I try
> nmake -nologo -f Make_mvc.mak if_ole.obj

Why?  Is the rule for .cpp.obj in Make_mvc.mak not used?  That sounds
like a bug.  But I find it hard to believe, since building if_ole.obj is
fine when it's being done as part of the dependencies.  It should not be
different when it's build separately.

> The difference is that our coding changes the effect of the .c.obj
> default rule but does not change the effect of the .cpp.obj rule.

The default rules are not to be used.  I don't see why they would be.

--
hundred-and-one symptoms of being an internet addict:
234. You started college as a chemistry major, and walk out four years
     later as an Internet provider.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: vim7: Make_mvc.mak

Walter Briscoe
In message <[hidden email]> of Tue, 5 Jul
2005 11:29:51 in , Bram Moolenaar <[hidden email]> writes

>
>Walter Briscoe wrote:
>
>> Let me try again:
>> The default      rule for .c.obj   uses CFLAGS
>> The Make_mvc.mak rule for .c.obj uses CFLAGS
>> The default      rule for .cpp.obj uses CPPFLAGS
>> The Make_mvc.mak rule for .cpp.obj uses CFLAGS rather than CPPFLAGS.
>>
>> So, I can get something sensible when I decide to do, for example,
>> nmake -nologo -f Make_mvc.mak buffer.obj
>>
>> Unless we make some change, I do not get anything sensible when I try
>> nmake -nologo -f Make_mvc.mak if_ole.obj
>
>Why?  Is the rule for .cpp.obj in Make_mvc.mak not used?  That sounds
There is no such rule. There is a .cpp{$(OUTDIR)/}.obj rule. If that
rule used $(CPPFLAGS) where it currently uses $(CFLAGS), I would be
happy.

>like a bug.  But I find it hard to believe, since building if_ole.obj is
>fine when it's being done as part of the dependencies.  It should not be
>different when it's build separately.
$(OUTDIR)/if_ole.obj, not if_ole.obj is normally built.
Using $(CFLAGS)   in .c{$(OUTDIR)/}.obj   affects         .c.obj
Using $(CFLAGS)   in .cpp{$(OUTDIR)/}.obj does not affect .cpp.obj
Using $(CPPFLAGS) in .cpp{$(OUTDIR)/}.obj would affect    .cpp.obj
That would be two one-line changes; I made one. I am lazy.

>
>> The difference is that our coding changes the effect of the .c.obj
>> default rule but does not change the effect of the .cpp.obj rule.
>
>The default rules are not to be used.  I don't see why they would be.
Symmetry.
.c{$(OUTDIR)/}.obj   is a particular   transformation of .c.obj
.cpp{$(OUTDIR)/}.obj could be the same transformation of .cpp.obj
It costs you little; it helps me more.

Did you not see how I generate .i files?
My technique does not work for files such as $(OUTDIR)/if_perl.obj which
have a specialised rule. I have not needed to make such .i files.
If I did, I would produce a technique to make OUTDIR equal "."

I will retain this as a private change. Delivering it is too expensive.
--
Walter Briscoe