getCommandFileSwitch() on CommandLineCompiler

Help
2006-06-26
2013-04-24
  • Markus Wankus

    Markus Wankus - 2006-06-26

    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?

     
    • Curt Arnold

      Curt Arnold - 2006-06-26

      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.

       
    • Markus Wankus

      Markus Wankus - 2006-06-26

      Thanks for the reply.  That makes sense.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks