Re: dllobject/libobject

Lars Ivar Igesund wrote:

> > > Also, another problem, dmd don't get the sob DLLOBJSUF, it need
> > > .obj. How/where should this be set up?
> >
> > Do you mean that using ".sob" does not work?  This is a fake suffix,
> > used to separate the object compiled for use in a dll from the same file
> > compiled for linking in a program.  What is the error you get when using
> > ".sob"?
> 
> The dmd compiler complains.

Hmm, that is annoying.  You could try setting DLLOBJSUF to ".sh.obj" in
the main default.vim.  I can't predict what side effects that has.

See further below for an idea to handle object suffixes more clever.

> > > A child recipe problem I forgot to mention in my last mail; If the
> > > objects are kept in a subdir and pointed to through :child, there
> > > aren't created any dependency log in the subdirs.
> >
> > Do you mean the "file.c.aap" file that contains the automatically
> > generated dependencies?
> 
> Hmm, I know what I meant, but I'm not able to reproduce completely
> with a minimal example.
> 
> I have tried to make a good minimal example to test this stuff, but I think
> that something don't work somewhere, quite possible in my recipes.
> 
> The 'project' have this structure:
> 
> main.aap
> bar.d
> /foodir
>     main.aap
>     subbar.d
> 
> /foodir/main.aap looks like this:
> 
> Source = subbar.d
> _top.subbar_obj = `src2obj(Source)`
> all: $_top.subbar_obj

You are using the "all" target in a child recipe.  Since the presence of
the "all" target has a higher priority than building the results of the
":program" or ":dll" command in the parent recipe, you would need to run
"aap foo" to tell Aap to build the program or dll instead of making the
"all" target.

I suppose you would like that running Aap without arguments in the
subdirectory builds the object files.  I am afraid I have no simple
solution for this at the moment.  All I can think of is using a Python
condition:

	@if not _no.TOPDIR:
	 	all: $_top.subbar_obj

This isn't very nice.  Perhaps we should add something like a "default"
target, which is used when there is no "all" target or targets from
":program"?  Then you could do:

	default: $_top.subbar_obj

But the priority between "all", "default" and ":program" items isn't
obvious.

Another solution could be to only use the "all" target of the toplevel
recipe and ignore the ones in child recipes.  But then the problem is
how to invoke the "all" target of the child recipe from the parent
recipe.  Hmm, scopes for virtual targets...?  Or the user just has to
give an additional virtual target:

	all subdir_all {virtual} : $_top.subbar_obj

> In the first test, main.aap looked like this:
> 
> :child foodir/main.aap
> :program foo : bar.d
>                        foodir/$*subbar_obj
> 
> Running aap, gave the log attached as 'log1'
> 
> Then I removed the created object files and changed main.aap:
> 
> :child foodir/main.aap
> :dll foo :   bar.d
>                foodir/$*subbar_obj
> 
> Running aap now, gave the log attached as 'dlllog'

[...]

> error:	Error in recipe "c:/projects/code/foo/main.aap" line 3: Do not =
> know how to make an dllobject out of "foodir/build-nt\subbar.obj"

In che child recipe you added an ordinary object file to $subbar_obj.
Then you use this object file with ":dll", which wants to link dllobject
files together.  That doesn't work.

The problem is that "src2obj(Source)" results in an ordinary object.  In
a previous message you mentioned that objects and dllobjects are
identical for this langauge.  But Aap doesn't know that and thinks it is
an error.

The simplest solution is to do:

	:attr {filetype = dllobject} $_top.subbar_obj

But that only works in this specific situation.

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.

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.

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

Hmm, perhaps we should keep the simple and predictable src2obj()
function and add a new one that is clever.  It would do something like
this:

	foreach item in source:
		# decide on the suffix to use
		if target == dllobject:
		    suffix = $DLLOBJSUF
		elif target == libobject:
		    suffix = $LIBOBJSUF
		elif target == ltobject:
		    suffix = $LTOBJSUF
	        else:
		    suffix = $OBJSUF

		filetype = filetype_of(item)
		if exists("src2obj_" + filetype):
			# Special handling was defined for this filetype
			result = eval("src2obj_" _ filetype, suffix, args)
		else:
			# Use the default hanlding
			result = src2obj(item, suffix)

-- 
ARTHUR:  No, hang on!  Just answer the five questions ...
GALAHAD: Three questions ...
ARTHUR:  Three questions ...  And we shall watch ... and pray.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// 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