Re: Language module support modified
Bram Moolenaar <[email protected]>
| Newsgroups | gmane.comp.tools.aap.devel |
|---|---|
| Message-ID | <[email protected]> |
Lars Ivar Igesund wrote:
> > I have just checked in version 1.039. Please try out this version. If
> > the D, qt and libtool modules look OK now then I'll make a .zip file
> > release.
>
> Still not in anon CVS.
SourceForge is still working on upgrading their CVS servers...
You can follow the hints on the Aap download page to use another
location for the CVS server, that sometimes helps.
> I have another request/wish though. (I will try to implement it myself
> if possible.)
>
> After looking at other D projects, I see that compilation of one and
> one file is uncommon. Instead all of the sourcefiles are sent to the
> compiler at once (and in most cases linked). The reason is that this
> is faster than the other way. The Digital Mars D compiler is so fast
> that compiling all files at once seems to be faster than updating only
> changed files. (I believe this is true for the the DMC compiler too.)
> Doing it this way also functions as a workaround for what I think
> is a dependency bug in the compiler.
> (Note that the speed difference is noticable, but not something that
> I was aware of before looking at other projects. It is not bothering
> me in any way.)
>
> Compiling and building a dll would then be just a
> dmd <switches, libs, includepaths, etc> -offoo.dll sources
>
> I understand that this might defeat some of the purpose of aap as
> it will remove the need for dependency checking (which isn't
> implemented for D, btw...), but having the choice of doing it this
> or way or that, is what I actually want. Later D compilers and/or
> versions for other platforms will most likely be much slower
> (for example gdc), and then the way it works today will be
> indispensable again.
>
> If this were to be done, how and where should the changes be?
> Would it be possible to do it with routes, rules and actions?
>
> I kinda thought of something like
>
> :program {all-in-one-go} foo: foo1.d
> foo2.d
> ..
> ..
> foon.d
I think this is a common request for fast compilers. It shouldn't be
difficult, you only need two things:
- An action to turn source files into a program (or dll or lib).
Nothing new in Aap, just an extra action in the D module.
- Give the user a choice whether he wants to use intermediate object
files or not. An argument to ":program" (and :dll and :lib) indeed
seems appropriate for this. This can probably be implemented in
add_buildrule() in DoAddDef.py. The function probably needs to split
up to take care of the choice between using object files or not.
I don't see a problem with dependency checking. It's only that when one
include file changes all the sources are compiled. And that's what the
user had chosen.
Something that would be more difficult: Some compilers can be told to
compile a list of sources files and turn each into an object file. This
is faster when the startup time of the compiler is significant, and it
can cache included files. The trouble is that Aap would have to collect
compilation commands with identical arguments and issue them all at
once. And make sure he results all go to the same directory. And
handle failure of one of the source files in a proper way. This sounds
too complicated to justify the speed improvement to me. But on slow
systems it might matter.
--
hundred-and-one symptoms of being an internet addict:
124. You begin conversations with, "Who is your internet service provider?"
/// 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: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php