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.

Close

Link Order preserved, but not Compile Order

Help
2005-03-11
2013-04-24
  • Markus Wankus
    Markus Wankus
    2005-03-11

    Can someone explain why this happens?  I have a simple application where I want to specify compile order and link order.  Playing with the linker arguments I found I could do this by specifying the filesets individually in my build file like so:

    <linker>
        ...args...
        <fileset dir="${project.dir}" file="Debug/junk.obj" />
        <fileset dir="${project.dir}" file="Debug/junker.obj" />
        <fileset dir="${project.dir}" file="Debug/junk2.obj" />
    </linker>

    This works as expected, and my files get linked in the order specified.  I decided to extend this to the compiler and found to my horror the command line is repeatably random compared to that of the linker.  It is probably taking the order of the hash set, but why is this different?  They use the exact same superclass - ProcessorDef, which looks to have a Vector storing the filesets.  How the heck does it end up in the wrong order? 

    My debug output is as follows:

    ConditionalFileSet: Setup scanner in dir C:\eclipseSDK3.0.1\runtime-workspace\Tester with patternSet{ includes: [crap/junker.cfs] excludes: [] }
    ConditionalFileSet: Setup scanner in dir C:\eclipseSDK3.0.1\runtime-workspace\Tester with patternSet{ includes: [junk.cfs] excludes: [] }
    ConditionalFileSet: Setup scanner in dir C:\eclipseSDK3.0.1\runtime-workspace\Tester with patternSet{ includes: [junk2.cfs] excludes: [] }
              [cc] 3 total files to be compiled.
              [cc] cfcc -bSK3 --lst -g -c C:\eclipseSDK3.0.1\runtime-workspace\Tester\junk2.cfs C:\eclipseSDK3.0.1\runtime-workspace\Tester\junk.cfs C:\eclipseSDK3.0.1\runtime-workspace\Tester\crap\junker.cfs
              [cc] Setting environment variable: MCINCLUDE=C:\ECLIPS~2.1\include\sk3
    Execute:Java13CommandLauncher: Executing 'cfcc' with arguments:
    '-bSK3'
    '--lst'
    '-g'
    '-c'
    'C:\eclipseSDK3.0.1\runtime-workspace\Tester\junk2.cfs'
    'C:\eclipseSDK3.0.1\runtime-workspace\Tester\junk.cfs'
    'C:\eclipseSDK3.0.1\runtime-workspace\Tester\crap\junker.cfs'

    The ' characters around the executable and arguments are
    not part of the command.

    Debug.link:
    Adding reference: eclipse.progress.monitor
    ConditionalFileSet: Setup scanner in dir C:\eclipseSDK3.0.1\runtime-workspace\Tester\Debug with patternSet{ includes: [junk.obj] excludes: [] }
    ConditionalFileSet: Setup scanner in dir C:\eclipseSDK3.0.1\runtime-workspace\Tester\Debug with patternSet{ includes: [junker.obj] excludes: [] }
    ConditionalFileSet: Setup scanner in dir C:\eclipseSDK3.0.1\runtime-workspace\Tester\Debug with patternSet{ includes: [junk2.obj] excludes: [] }
              [cc] 0 total files to be compiled.
              [cc] Starting link
              [cc] cfcc --map --entry=main --mem0=0x1000/0x2FFF --mem0=0xFFE0/0xFFFF --mem1=0x0120/0x17FF --mem1=0x8000/0xBFFF --mem2=0x0120/0x07FF --mem3=0x0020/0x011F --mem4=0x0000/0xFFFF -o Tester.abs junk.obj junker.obj junk2.obj
              [cc] Setting environment variable: MCLIB=C:\ECLIPS~2.1\lib\sk3
    Execute:Java13CommandLauncher: Executing 'cfcc' with arguments:
    '--map'
    '--entry=main'
    '--mem0=0x1000/0x2FFF'
    '--mem0=0xFFE0/0xFFFF'
    '--mem1=0x0120/0x17FF'
    '--mem1=0x8000/0xBFFF'
    '--mem2=0x0120/0x07FF'
    '--mem3=0x0020/0x011F'
    '--mem4=0x0000/0xFFFF'
    '-o'
    'Tester.abs'
    'junk.obj'
    'junker.obj'
    'junk2.obj'

    Notice how order is preserved in the linker, but not the compiler.  What's going on here, internally?

    Mark.

     
    • Curt Arnold
      Curt Arnold
      2005-03-11

      The ordering attempts to compile the most likely to fail first.  The idea was that if you had a big project that took a long time to develop and you changed foo.h that was used by just about everything, it was beneficial to the developer that things files that had changed or directly included foo.h (say foo.cpp) got rebuilt first since they were most likely to fail.  It wouldn't speed up a successful build, but it could radically speed up time to failure on a bad build and substantially increase the number of iterations.

      Preserving compile order was never a design goal, especially since the Ant fileset didn't guarantee any order to begin with.  I can see why you could want to preserve link order to control layout in the a binary.  I don't know why compile order would be significant.  However, if you want to do either, probably the best way is to add a <layout> or <sequence> element for the processors.

       
      • Markus Wankus
        Markus Wankus
        2005-03-12

        Ah.  Well - thanks for the reply - that makes sense.

        I agree compiler order isn't all that important - the problem is I went ahead and blindly implemented a GUI that allowed you to specify order for both the compile and link stages, and I made the assumption the fileset ordering worked on both....I guess I shouldn't have assumed. :o(

        I guess I'll look at implementing some sort of ordering in my compiler/linker, or revisit the GUI.

        Thanks again,
        Mark.