Re: dllobject/libobject

I wrote:

> A generic solution would be to tell ":dll" that it can use ordinary
> object files when "d" source files are used.  But how to do that from a
> "d" language module?  We probably have to do this by adding attributes
> to the object files, so that ":dll" can see that they are OK to use as
> dllobjtype.

If a compile action is defined for "d" to "dllobject" then ":dll" will
use it.  Thus it should only be a matter of defining a compile action
for all object types:

	:action compile object,libobject,dllobject,default d
	    :sys dcc $source -o $target

I don't see an obvious way to specify that "object", "dllobject" and
"libobject" are actually the same.  So long as we don't really need
this, I think we can leave it out.

The real problem actually occurs when dllobject and libobject files have
the same extension, but the _are_ different.  Aap then doesn't protect
the user for mixing up the files and will happily try to link the wrong
object files.  The user should use a different $BDIR.  But it would be
nice if Aap can warn the user when he is doing something that won't
work.

> I suppose key to this story is that src2obj() should be language
> specific.  For a D file it could add an attribute to the object file
> that says it can both be used with :program and :dll.  Thus instead of
> explicitly giving a different suffix argument to src2obj() it could be
> much smarter: recognize the filetype of the source and select the object
> suffix and other attributes based on that.

I have implemented this now.  src2obj() recognizes the filetype of the
source and uses a different variable for the object file suffix.  For
example, src2obj("foo.d", "OBJSUF") uses $D_OBJSUF.  If it doesn't exist
then if falls back to $OBJSUF.

This is a very simple method.  In your language module you can set four
variables to specify the extension to be used:

	D_OBJSUF = $OBJSUF
	D_DLLOBJSUF = $OBJSUF
	D_LIBOBJSUF = $OBJSUF
	D_LTOBJSUF = $OBJSUF

In this example they are all equal, you mentioned that is how the "d"
language works.

> We should also have a "src2dllobj()" and "src2libobj()" then.  Or use an
> argument to specify "dllobject" or "libobject" (and "ltobject" I
> suppose).

I have now solved this by using the "sufname" argument for src2obj().
This already existed, thus it's a very simple change.  The only thing is
that the filetype detection may prepend the filetype to the variable
name.  If you don't want this, the new "auto" argument can be set to
zero.

The new docs for src2obj():

src2obj(source, sufname = "OBJSUF", auto = 1)

    Transform a string, which is a list of source files, into the
    corresponding list of object files. Each item in "source" is changed
    by prepending $BDIR and changing or appending the suffix specified
    with "sufname" (defaults to $OBJSUF).

    The attribute "var_BDIR" is used instead of $BDIR when the attribute
    exists. The attribute "suffix" is used for the suffix instead of
    using the "suffix" argument when the attribute exists.

    When the "auto" argument is non-zero (the default) then the filetype
    of the source file will be prepended to the "sufname" (in upper case
    and adding an underscore). Thus for a Java source file, $JAVA_OBJSUF
    will be used. When it does not exists "sufname" is used. When this
    is not wanted the "auto" argument must be set to zero.


Aap version 1.032 is available now.

Lars, please check if this works well with your "d" module.  With a bit
of luck Adriaan manages to implement ":import" and then it should all
work.

-- 
hundred-and-one symptoms of being an internet addict:
20. When looking at a pageful of someone else's links, you notice all of them
    are already highlighted in purple.

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf