Re: [Ant-contrib-developers] About <libset>, always compile 1 file, and env. setup

[Curt A. <ca...@ho...>]

From: "Dominique Devienne" <DDe...@lg...> wrote:
> The first small JNI dll and the little exe were easily taken care of,
since
> mostly independent code, only after I solved setup issues (I'll come back
on
> those later). Thanks for the documentation of the tasks, it's quite nice.
> Having examples to follow would have helped, but thru experimentation and
> the good tasks docs, I managed to have things working faster than I
thought
> I would. Actually, I would probably have given up without this early
> (lucky?) success. Anyways...

There is a fairly complex sample build file for Xerces-C that I thought that
I put into the distribution.  If not, it is in the CVS as
cpptasks/samples/xercesc.ant

> The main JNI dll was what I was really interested on. It's the JNI layer
on
> top of the 4 big MS VS workspaces (.dsw), each composed of many projects
> (.dsp). Adding to the <includepath> to compile was easy, offering many
> choices of types to pass on (<fileset>, <filelist>, <dirset>, etc...), but
I
> was surprised to see how <libset> was poor in comparison...
>
> 1) <libset>
> No option to use a <filelist>, or even a <fileset> (if one doesn't care
> about the order of the libraries).

If you are just adding library filenames to the linker command, you can just
place the appropriate <fileset> as a child of a <linker> or <cc> element.
For Microsoft Linker builds,

<cc name="msvc">
    ...
   <libset dir="${mylib.dir}" libs="mylib"/>
</cc>

is equivalent to:

<cc name="msvc">
    ...
    <fileset dir="${mylib.dir}" includes="mylib.lib"/>
</cc>

They would have different effects for GCC or similar compilers, libset would
result in a "-L  mydir -l mylib" fragment added to the command line, while
<fileset> would result in "mydir/mylib.lib" being added to the command line.

>
> In my particular case, using a <fileset> would have been convenient, since
I
> could have re-used the same fileset (thanks to its 'id') in my distrib
> target as well, in addition as inside <libset> for <cc>. These are
> enhancement requests I guess.

You could reuse the current form by placing the libset within a linker
element and referencing or extending the linker.

Earlier versions of cpptasks did allow <fileset> within <libset>, however it
did not properly address the platform conventions ("lib" prefix and ".so" or
".a" extensions for gcc like compilers, no prefix and ".lib" extensions of
Microsoft like compilers).  I guess you could clone the FileSet and then add
the prefixes and suffixes before evaluating the fileset, however that seems
a decent amount of work.

>
> 2) Always recompiles
> Now on to something that might be a bug: After doing a clean build, I did
> several builds without changing anything, and <cc> still compiles a couple
> files, every time! I tried turning on debug in Ant, to find out why these
> two file appear out-of-date, but didn't get much debug output from <cc> at
> all. Of course, recompiling triggers a re-link, which is not that great.

I'll try to add more diagnostics when verbose.

>
> And just as I write this, it finally downed on me that I was using the
same
> objdir for all my 3 <cc> invocations, and I had two files similarly names
> (although not with the same case, but Windows being what it is...). After
I
> changed my build.xml to have different 'objdir' values, then it behaved
> perfectly.

The expectation is that you would use distinct directories for different
types of builds.  Any change in the command line (other than the files
names) or any change in the compiler identification string will result in
the object file being marked out of date.  I'll expand the comments to
mention this.

> But that brings up another issue I think:
> The flattening of all objects in a single directory is bound to result
> trouble when the same source short name exists in different directories,
and
> they all get compiles at the same time!!! My long term goal was to also
use
> <cc> to compile the 4 big Visual Studio workspaces, instead of having
msdev
> on windows, and gnu makes on the unix side... And I have such similarly
> named files belonging to different DLLs right now, but I wanted to compile
1
> DLL per workspace (instead of 10) using a single <cc> invocation. In any
> case, it seems dangerous to not even detect collisions like that.

cpptasks should detect object filename collisions within one <cc> task (code
around line 148 in TargetMatcher).  For example, if you did:

<cc>
    <fileset dir="foo1" include="foo.cpp"/>
    <fileset dir="foo2" include="foo.cpp"/>
</cc>

You should get a BuildException.  There is no collision detection between
distinct <cc> tasks in one build or multiple builds of the same project
running simultaneously.  However, I don't think any build tool robustly
handles multiple instances competing for the same output directories.

If you can build with Visual Studio, I would think that you already avoid
building identically named object files in one project since they compile
all their files for a configuration into one directory.  Trying to create a
tree structure in the build directory (like a Java build) is problematic
when the source files come from locations that are not descendents of the
build directory.

>
> 3) Env. Setup
> The documentation simply says: 4) Set path and environment variables to be
> able to run compiler from command line. That is simply not acceptable to
me.
> One of the great things Ant provides is the ability to encapsulate all
> environment dependent things into user-specific properties files (under CM
> control).

Definitely, you would like to avoid putting any compiler or installation
specific settings in the body of a build script.  The current approach
avoids that by expecting that the compiler is on the path or that you have
run VCVARS32.bat.  I'd try to add a newenvironment attribute and allowing
<env> children for <linker>, <compiler> and <cc>.  It don't think that
cc-environment would add any additional reuse since the environment
variables almost always be associated with one specific compiler, so you
could just add then to a base <compiler> element that similar <compiler>'s
extend.