mingw32-make : "Input line too long" issue

Question

We have a Makefile which runs on a Windows 2003 machine and we are using mingw32-make for it. Since the Makefile has many include paths, it exceeds the buffer size of 8K that the cmd can handle [Ref - http://support.microsoft.com/kb/830473/EN-US/due to which the compilation results in "input line too long" issue.

I wanted to know the following -

1. What would be the best way to optimize the Makefile as I have already removed unwanted compiler switches, include paths etc.

2. Is there any way we can put all the INCLUDE paths in one .txt file and import it in the Makefile.I could not find any mingw32 documentation for the same.

Any other inputs/hints/reference links are most welcome.

Thanks,
-HJSblogger

Answer 1

One approach we took (this wasn't because we ran out of command-line space, just because we wanted a cleaner build system) was to have each "module" do its build in passes.

So, for example, say you have 3 modules, A, B and C.

Your control makefile simply calls each modules makefile with the same target.

Then we set the targets to be a consistent clean, header, lib and exec.

So, the control makefile was something like:

modules=A B C
clean:
    for i in $modules:
        ( cd $i ; make clean ; cd .. )
header:
    for i in $modules:
        ( cd $i ; make header ; cd .. )
lib:
    for i in $modules:
        ( cd $i ; make lib ; cd .. )
exec:
    for i in $modules:
        ( cd $i ; make exec ; cd .. )

Every module that had header files needed by other modules copied those header files into a central location during the header phase. Then, during the lib or exec phase, each module only had to use that central location to locate all of its headers. This also restricted modules to only using those headers that were published to the central location by other modules.

Similarly, every module that created a library needed by the exec phase, copied that library to a central location. This greatly minimized the -I (include directory) and -L (library directory) clauses in the build commands.

Using that scheme, you could rebuild the entire thing just by executing make clean header lib exec at the top level (or leave off the clean for a proper make build, taking into account the dependencies).

That's one way to get around your problem, but I'm actually wondering how you're exceeding the limit. 8K, even at 25 characters per path, would require about 300 distinct include paths. Is your hierarchy really that voluminous?

Update 1:

If you're looking for a quick'n'dirty way to get it working without changing the makefile "architecture", you write a script which, given a list of directories, will copy all header files from those directories to a central location.

Then run that as the first step in all your rules and modify the include statements in your compile lines to just reference that location rather than the large list. You could even do the copy in stages (e.g., 20 directories at a time x 20 times could handle 400 directories in total).

This gives you the same effect as my proposed solution with smaller changes to the makefiles.

Update 2:

One other solution, as you stated in your comments, was to alias a path.

You should be able to do that with subst.exe such as:

> subst x: "c:\Documents and Settings\Pax\My Documents\Not my directory"
> dir x:
  Volume in drive X has no label.
  Volume Serial Number is 8AA3-703A

  Directory of X:\

  08/09/2009  10:12 AM    <DIR>          .
  08/09/2009  10:12 AM    <DIR>          ..
  24/08/2009  01:54 PM             6,409 p0rn_sites.txt
  09/07/2008  02:49 PM    <DIR>          downloaded_p0rn
  : : :
  09/07/2008  02:52 PM    <DIR>          other_suspect_stuff
                 3 File(s)         18,520 bytes
                18 Dir(s)  63,840,849,920 bytes free

> subst x: /d
> dir x:
  The system cannot find the path specified.