cc outfile not consistant

  • MJA

    MJA - 2007-05-08

    I've come to learn that when you specify an "outfile" in the cc task, the task may modify the actual outfile by adding a prefix and/or extension.  Keyword: "may".  This seems absurd to me.  In my post-compile I have to create a symbolic link to the outfile.  How am I supposed to create a symbolic link to a file I'm not guaranteed to know the exact name of?  Not to mention run-time scripts that need to call the executable name, or other apps that need to link in a library I create.  Adding prefixes and postfixes to the outfile is a nice feature if and only if its guaranteed every time.  Otherwise it will do more harm then good.

    Does anyone know how to guarantee your outfile will remain what you specify?  When compiling/linking a library, I added my own prefix (lib) and extension (.a) to my outfile, and the cc-task still added its own prefix and extension.  So the target ended up being named: liblibMyLib.a.a.  And when I compile/link an executable, cc task does not add the .exe extension.  So should I add my own .exe extenstion?  Only to find out on some other platform cc-task will add as well?  No consistancy.

    FYI, at the moment, I'm doing all my compiling on a Unix w/s, using Solaris-8.

    • Caleb Cittadino

      Caleb Cittadino - 2007-05-08

      The pre/post fixes are based on your platform and compiler (I believe).  For me, when I build a library on Mac I get:

      -Pre: lib
      -Post: .a

      -Pre: lib
      -Post: .dylib

      In windows I get:

      -Pre: none
      -Post: .lib

      -Pre: none
      -Post: dll

      As for executables in windows I get .exe and Mac .app.

      This is correct given that the native compilers on both platforms put these pre/post fixes on as well.  The CC task is just following suit. 

      For CC task to make the correct decisions make sure all your attributes are set correct, mainly "outtype".


      • David Haney

        David Haney - 2007-05-08

        I like the platform abstraction that CC tasks provides around naming outfiles, however I've run into similar issues to what Mike's seeing, with not knowing what filename was eventually created.  This is particularly troublesome if I want to specify the result file in a fileset so that it can be copied to some other location.  I can think of two options that could help address this:

        1) Provide an attribute on <cc> indicating whether you want dynamic outfile creation.  This would provide an out for users who want to explicitly control the name, and might want to violate the convention for that platform.  They will lose some amount of portability, however they could probably compensate for that in their own infrastructure if necessary.

        2) Provde an attribute on <cc> indicating the name of a property that will be set with the expanded outfile name.  This won't give users control over the name, but will allow users to write portable code, and still provide them with the information necessary to do post-processing work on the result files.

        These aren't mutually exclusive so both *could* be implemented.  Are there any inclinations on which would be more useful, or at least more in line with the design goals for CC-tasks?


        • Curt Arnold

          Curt Arnold - 2007-05-08

          Option 2 should already be implemented.  There is already a outputFileProperty that can be specified on the cc task that specifies a property that should receive the expanded file name.

          • Phil

            Phil - 2007-08-16


            I found I was getting a problem like this when using g++ on Windows under Cygwin.
            I want to specify the output of my link as "HelloWorldCPP.dll", but instead I get "".
            Easily rectified with a "move" task, but not exactly clean and tidy.

            Is there some way to convince CC that I'm using Windows?  I didn't see a way to specify architecture (not sure whether this would even help).  At any rate the ccptask docs seem wrong as they suggest that specifying an extension will override this behaviour, which it didn't for me:-

               Sets the output file name. If not specified, the task will only compile files and not attempt to link. If an extension is not specified, the task may use a system appropriate extension and prefix, for example, outfile="example" may result in "" being created."

            Not a show stopper, but might be worth tidying this up.

            Here's my <cc> and <move> blocks in case maybe I'm being a muppet:

            <cc multithreaded="true" outtype="shared" outfile="${build}\${basename}.dll">
                <compiler name="g++">               
                        <dirset dir="C:\j2sdk1.4.2_15\include" />
                    <compilerarg location = "start" value = "-mno-cygwin"/>
                    <fileset file="${basename}.cpp" />
                <linker name="g++">
                    <linkerarg location ="start" value = "-mno-cygwin"/>
                    <linkerarg location ="start" value = "--add-stdcall-alias"/>
            <move file="${build}\lib${basename}" tofile="${basename}.dll"/>


    • MJA

      MJA - 2007-05-10

      I overlooked the "outputfileproperty" feature of cc.  Using that, I can create my symlink name to be whatever I want, and just point it to the the "outputfileproperty'.  That way my symlink name will always be consistant/known, no matter how cc decides to rename the physical output file (which will reside one directory down in debug or release directory). 

      Thanks all!


Log in to post a comment.