On Wed, 14 Oct 2009, Szak�ts Viktor wrote:
Hi,
> I'll commit something, but I'd like to ask you to test it.
> Feel free to even make corrections.
> Before I do, I have a few questions:
> - Shouldn't Harbour compiler also use this same .d format, so
> we can use the method for .prg files, too?
I'm not sure I understood you.
Are you asking about adding to current -sm output "<desfile>: "
at the beginning of each line?
If yes then I haven't implement it intentionally because final
<destfile> may be different then the one which harbour compiler
can set. Harbour does not generate .{o,obj} files naively and
user may need it as destination rule. Anyhow I also plan to add
option to create .d files by compiler in one pass with compilation
so they will be created without any noticeable speed overhead and
in this case I will have to arbitrary chose <destfile> extension
using information from -g? switch though maybe I'll try to add also
an option to set the extension by user because in many cases
user will need .{o,obj} but with -gc* used to generate .c files.
> - Am I right that these .d files are supposed to be autodetected?
How thay will be used depends on user. The general idea is
> If so, what is the name? filename.d or filename.c.d?
filename.d and it's -MD GCC option behavior.
> Here I have a little worry that this extra file existence
> check in mass will slow down normal make process, especially
> on network shares. I have projects with up to 800 files.
You do not have to make it automatically. Just simply recognize .d
files given by user in command line with wildcard extension in non
POSIX shell environment and load all dependencies sets inside each
of them into one hash table. Then inside code which checks for
dependencies check if scanned file belongs to this hash table and
if yes then take defined dependencies list.
> Other options are passing these .d files explicitly, or
> add a new switch to enable parsing of .d files, like -head=d.
exactly though -head=d should only disable other methods used to
detect dependencies. HBMK2 should always recognize .d files given
at command line and load dependencies into hash table. This hash
table should always be used to check if file has to be rebuilt.
If it does not give positive answer then there is a question if
we should try to use other methods. And here we have 3 choices:
1. never use other methods
2. always use other methods
3. use other method only if '! <destfile> $ hDeps' so adding
<destfile> to one of .d files even with empty dependencies list
will disable other method used to detect if file should be
recompiled.
I can imagine situations where each method can be usable so maybe
we should have option to chose one of them.
I'm leaving the decision for you. You know HBMK2 code much better
then any of us.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
