Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I have run into a case where my command line length ballooned over the limited returned by getMaximumCommandLength(). This caused my toolchain to break because Cpptasks then tries to write the options to a file and calls getCommandFileSwitch() to figure out how to pass the file to the toolchain. However, since this method is not implemented, Cpptasks just blows up with a NullPointerException (probably should file a separate bug about this).
Anyway, when I went to implement getCommandFileSwitch() for my toolchain I noticed that it is an abstract method on linkers, but not on compilers? Is there a reason for this or is it an oversight? I don't see why it wouldn't apply to a compiler as well.
Currently it looks like the compiler doesn't even follow the same heuristic anyway. If the length is too long, it just bails, whereas a linker will try to write a temporary options file and feed that to the tool. Why the difference?
The reason for the difference between compilers and linkers is that with compilers the better resolution is to reduce the number of files compiled per step and run the compiler multiple times. With a linker, you do not have the option to split the work between multiple invocations.
I had not run into a case where compiling just one file overflowed the command line length and I could see that it might not behave nicely.
Thanks for the reply. That makes sense.