Tom S wrote:
I tested it on a single-module program before posting. Basically void
main() {} and a single unused function void fooBar {}. With -g,
something with the function's mangled name ended up in the executable.
Without -g, the linker was able to remove the function (I ran a diff on
a
Walter Bright wrote:
Also, if you specify a .obj file directly to the linker, it will put all
of the symbols and data in that .obj file into the executable. The
linker does NOT remove functions.
What it DOES do is pull obj files out of a library to resolve unresolved
symbols from other obj
Tom S wrote:
Personally I'm of the opinion that functions should
be explicitly marked for CTFE, and this is just another reason for such.
I'm using a patched DMD with added pragma(ctfe) which instructs the
compiler not to run any codegen or generate debug info
functions/aggregates marked as
Tom S wrote:
When building my second largest project, DMD eats up about 1.2GB of
memory and dies (even without -g). Luckily, xfBuild allows me to set the
limit of modules to be compiled at a time, so when I cap it to 200, it
compiled... but didn't link :( Somewhere in the process a library is
Walter Bright wrote:
Tom S wrote:
Personally I'm of the opinion that functions should be explicitly
marked for CTFE, and this is just another reason for such. I'm using a
patched DMD with added pragma(ctfe) which instructs the compiler not
to run any codegen or generate debug info
Walter Bright wrote:
Tom S wrote:
When building my second largest project, DMD eats up about 1.2GB of
memory and dies (even without -g). Luckily, xfBuild allows me to set
the limit of modules to be compiled at a time, so when I cap it to
200, it compiled... but didn't link :( Somewhere in the
Tom S wrote:
Walter Bright wrote:
Tom S wrote:
Personally I'm of the opinion that functions should be explicitly
marked for CTFE, and this is just another reason for such. I'm using
a patched DMD with added pragma(ctfe) which instructs the compiler
not to run any codegen or generate debug
Walter Bright wrote:
What you can try is creating a database that is basically a lib (call it
A.lib) of all the modules compiled with -lib. Then recompile all modules
that depend on changed modules in one command, also with -lib, call it
B.lib. Then for all the obj's in B, replace the
Tom S wrote:
Walter Bright wrote:
I don't really understand why the -lib approach is not working for
your needs.
I'm not sure what you mean by the -lib approach. Just how do you
exactly apply it to incremental compilation? If my project has a few
hundred modules and I change just one line
Walter Bright wrote:
Tom S wrote:
Walter Bright wrote:
I don't really understand why the -lib approach is not working for
your needs.
I'm not sure what you mean by the -lib approach. Just how do you
exactly apply it to incremental compilation? If my project has a few
hundred modules and I
Tom S wrote:
Walter Bright wrote:
Tom S wrote:
Walter Bright wrote:
I don't really understand why the -lib approach is not working for
your needs.
I'm not sure what you mean by the -lib approach. Just how do you
exactly apply it to incremental compilation? If my project has a few
hundred
Walter Bright wrote:
What you can try is creating a database that is basically a lib (call it
A.lib) of all the modules compiled with -lib. Then recompile all modules
that depend on changed modules in one command, also with -lib, call it
B.lib. Then for all the obj's in B, replace the
Tom S wrote:
Walter Bright wrote:
What you can try is creating a database that is basically a lib (call
it A.lib) of all the modules compiled with -lib. Then recompile all
modules that depend on changed modules in one command, also with -lib,
call it B.lib. Then for all the obj's in B,
Walter Bright wrote:
Tom S wrote:
Walter Bright wrote:
What you can try is creating a database that is basically a lib (call
it A.lib) of all the modules compiled with -lib. Then recompile all
modules that depend on changed modules in one command, also with
-lib, call it B.lib. Then for all
Don wrote:
Walter Bright wrote:
Tom S wrote:
Walter Bright wrote:
What you can try is creating a database that is basically a lib
(call it A.lib) of all the modules compiled with -lib. Then
recompile all modules that depend on changed modules in one command,
also with -lib, call it B.lib.
Walter Bright wrote:
Tom S wrote:
Thus my suggestion of adding an option to DMD so it may emit template
instances to all object files that use them. If anyone has alternative
ideas, I'd be glad to hear them, because I'm running out of options.
Try compiling with -lib, which will put each
Tom S wrote:
Walter Bright wrote:
Tom S wrote:
Thus my suggestion of adding an option to DMD so it may emit template
instances to all object files that use them. If anyone has
alternative ideas, I'd be glad to hear them, because I'm running out
of options.
Try compiling with -lib, which
Tom S wrote:
As for my own impressions of this idea, its biggest drawback probably is
that the multitude of object files created via -multiobj strains the
filesystem.
Sure, but -multiobj and -lib generate exactly the same object files,
it's just that -lib puts them all into a library so it
Walter Bright wrote:
Tom S wrote:
As for my own impressions of this idea, its biggest drawback probably
is that the multitude of object files created via -multiobj strains
the filesystem.
Sure, but -multiobj and -lib generate exactly the same object files,
it's just that -lib puts them all
Tom S wrote:
Walter Bright wrote:
Tom S wrote:
As for my own impressions of this idea, its biggest drawback probably
is that the multitude of object files created via -multiobj strains
the filesystem.
Sure, but -multiobj and -lib generate exactly the same object files,
it's just that -lib
Walter Bright wrote:
I don't really understand why the -lib approach is not working for your
needs.
I'm not sure what you mean by the -lib approach. Just how do you
exactly apply it to incremental compilation? If my project has a few
hundred modules and I change just one line in one
Short story: DMD probably needs an option to output template instances
to all object files that need them.
Long story:
I've been trying to make incremental compilation in xfBuild reliable,
but it turns out that it's really tricky with DMD. Consider the
following example:
* module A
Tom S escribió:
Short story: DMD probably needs an option to output template instances
to all object files that need them.
Hi Tom,
What you describe here is very interesting and useful. I think of adding
an incremental builder to Descent in some point in the future and I'll
probably
On Fri, 11 Sep 2009 07:47:11 -0400, Tom S
h3r3...@remove.mat.uni.torun.pl wrote:
Short story: DMD probably needs an option to output template instances
to all object files that need them.
Long story:
I've been trying to make incremental compilation in xfBuild reliable,
but it turns out
Tom S wrote:
Thus my suggestion of adding an option to DMD so it may emit template
instances to all object files that use them. If anyone has alternative
ideas, I'd be glad to hear them, because I'm running out of options.
Try compiling with -lib, which will put each template instance into
25 matches
Mail list logo
