www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - exe file size

reply huurd <hurd 163.com> writes:
I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  

exe file appears to be a lot of meaningless repeat, how to remove it?
Nov 13 2008
next sibling parent Kagamin <spam here.lot> writes:
huurd Wrote:

 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  
 
 exe file appears to be a lot of meaningless repeat, how to remove it?

You can't.
Nov 13 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
huurd Wrote:
 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  
 exe file appears to be a lot of meaningless repeat, how to remove it?

The best strategy is probably to change the compiler a little so it avoids putting some of that stuff there in the first place :-) Bye, bearophile
Nov 13 2008
prev sibling next sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Thu, 13 Nov 2008 12:07:57 +0200, huurd <hurd 163.com> wrote:

 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size  
 is 800kb.

 exe file appears to be a lot of meaningless repeat, how to remove it?

It shouldn't be so big without debug info. Check your compilation options and make sure you're not including symbols (not passing -g when linking). -- Best regards, Vladimir mailto:thecybershadow gmail.com
Nov 13 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
huurd wrote:
 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  
 
 exe file appears to be a lot of meaningless repeat, how to remove it?

If you're using DSSS, try with oneatatime=false . THis will probably reduce it to 5-7M
Nov 13 2008
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
huurd wrote:
 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  
 
 exe file appears to be a lot of meaningless repeat, how to remove it?

<joke> use a program like upx </joke>
Nov 13 2008
prev sibling next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello huurd,

 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size
 is 800kb.
 
 exe file appears to be a lot of meaningless repeat, how to remove it?
 

22M is distastefully huge for a hello world example using dwt and dwtx :(. Like other's suggested, maybe debug info is getting compiled in due to a -g switch. The file size still may end up being several megabytes, though, even without the debug info. This is more of an annoyance, than a hindrance. DWT has a lot to offer; so most people end up coping with the size issue, especially if they know they can use something like upx to squeeze things tight. I can't exactly remember what the cause of this is, but I think it has something to do with scads of "hidden" D symbols (moduleinfo?) produced by the D compiler for projects that have a combination of (1) tons of modules and (2) many interdependencies amongst modules such that even a small project ends up linking in ALL (or nearly so) classes from the framework. This, unfortunately, is one of DWT's weaknesses. I wish the language could help DWT by fixing that, but I don't know if that is possible. Other alternatives that might help reduce the problem (I think) is integrating multiple modules into one file...but that tends to hinder the whole idea of organization and namespace clarity. If DWT were to do this, it would also break import compatibility with SWT. There are a few reasons why this approach is not desirable. But I hear you. I really don't like unnecessary bloat either. It would be great if we had some super smart tools that could pair things down a bit. -JJR
Nov 13 2008
parent reply huurd <hurd 163.com> writes:
I use The -O -release -inline , the size si 20M, there is no -g.
Nov 13 2008
next sibling parent reply huurd <hurd 163.com> writes:
the disassemble file is a lot repeat like "ADD [EAX],AL";
Nov 13 2008
parent reply Kagamin <spam here.lot> writes:
Jarrett Billingsley Wrote:

 On Thu, Nov 13, 2008 at 10:41 PM, huurd <hurd 163.com> wrote:
 the disassemble file is a lot repeat like "ADD [EAX],AL";

That's just 0s.

Hmm... Are they 4kb-long, I wonder?
Nov 14 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
Kagamin schrieb:
 Jarrett Billingsley Wrote:
 
 On Thu, Nov 13, 2008 at 10:41 PM, huurd <hurd 163.com> wrote:
 the disassemble file is a lot repeat like "ADD [EAX],AL";


Hmm... Are they 4kb-long, I wonder?

What does that mean? Are those stuffed space that gets disassembled like that. Or could be a hint to a bug in codegen?
Nov 14 2008
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello huurd,

 I use The -O -release -inline , the size si 20M, there is no -g.
 

Ouch. :( I know dwt + dwtx pulls in a lot of modules. I'm afraid this has been a niggling bother to me too, since I help port dwt, but I know there is no simple solution for this. BTW, is this on Linux or windows? If you are using linux, try using the "strip" command on the binary. It should make it much smaller. If not, well... the emphasis on dwt development right now is stability, completion (as in porting), and close tracking of the SWT version. Finding ways to make it smaller may be in the future (I've suggested such in prior posts), but doing so will be inextricably tied to the compiler/linker/language technology and what these are able to do to reduce the footprint. If these don't change somehow, there's little that can be done, other than make the oh-so annoying statement "Well, hey! These days, memory is so cheap and computers are so powerful that it really doesn't matter anymore" ;-). Somehow, that isn't very convincing, I know :-) Upx is the best option for now, I guess. 800 kb isn't all that bad, actually. -JJR
Nov 13 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Nov 14, 2008 at 2:38 PM, John Reimer <terminal.node gmail.com> wrote:
 Hello huurd,

 I use The -O -release -inline , the size si 20M, there is no -g.

Ouch. :( I know dwt + dwtx pulls in a lot of modules. I'm afraid this has been a niggling bother to me too, since I help port dwt, but I know there is no simple solution for this. BTW, is this on Linux or windows? If you are using linux, try using the "strip" command on the binary. It should make it much smaller. If not, well... the emphasis on dwt development right now is stability, completion (as in porting), and close tracking of the SWT version. Finding ways to make it smaller may be in the future (I've suggested such in prior posts), but doing so will be inextricably tied to the compiler/linker/language technology and what these are able to do to reduce the footprint. If these don't change somehow, there's little that can be done, other than make the oh-so annoying statement "Well, hey! These days, memory is so cheap and computers are so powerful that it really doesn't matter anymore" ;-). Somehow, that isn't very convincing, I know :-) Upx is the best option for now, I guess. 800 kb isn't all that bad, actually.

I think the build time of dwt apps is a much bigger issue right now than the size of exes. The size of exes can be reduced using hacks like upx, but there is no fix for the long build times as far as I know. --bb
Nov 13 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Bill,


 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.
 
 --bb
 

Totally agree. The size is just an annoyance. But currently the build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR
Nov 13 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:
 Hello Bill,


 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb

Totally agree. The size is just an annoyance. But currently the build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

Build times with the new dsss push me way past the sanity point, so I've gone back to 0.76, which I think may have never been released. I think I built it myself from sources. Build times with 0.76 are just barely tolerable with my app. But my colleague was telling me today that he wants to do his work on a small, non-DWT test app instead of the main app because the build times are too frustrating for him. If I were forced to use the latest DSSS, I'd defnitely be trying to do whatever I could to improve the build times, including using "make" if that's what it took. Hmm... Now that dmd -v will spit out all the modules imported, it might be possible to use that to create a makefile (or a make.deps for use by a makefile) automatically. --bb

I suggest people to try rdmd out. It comes with the standard distribution and I'd want to improve it based on feedback. http://www.digitalmars.com/d/2.0/rdmd.html Andrei
Nov 14 2008
next sibling parent Max Samukha <samukha voliacable.com.removethis> writes:
On Fri, 14 Nov 2008 02:04:55 -0600, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

Bill Baxter wrote:
 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:
 Hello Bill,


 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb

Totally agree. The size is just an annoyance. But currently the build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

Build times with the new dsss push me way past the sanity point, so I've gone back to 0.76, which I think may have never been released. I think I built it myself from sources. Build times with 0.76 are just barely tolerable with my app. But my colleague was telling me today that he wants to do his work on a small, non-DWT test app instead of the main app because the build times are too frustrating for him. If I were forced to use the latest DSSS, I'd defnitely be trying to do whatever I could to improve the build times, including using "make" if that's what it took. Hmm... Now that dmd -v will spit out all the modules imported, it might be possible to use that to create a makefile (or a make.deps for use by a makefile) automatically. --bb

I suggest people to try rdmd out. It comes with the standard distribution and I'd want to improve it based on feedback. http://www.digitalmars.com/d/2.0/rdmd.html Andrei

I'd use it if it worked on Windows. I'd also like to see in rdmd the feature of rebuild that enables generation of fully qualified names for doc files. Thanks!
Nov 14 2008
prev sibling next sibling parent reply BLS <nanali notthatwanadoo.fr> writes:
Andrei Alexandrescu Wrote:

 Bill Baxter wrote:
 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:
 Hello Bill,


 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb

Totally agree. The size is just an annoyance. But currently the build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

Build times with the new dsss push me way past the sanity point, so I've gone back to 0.76, which I think may have never been released. I think I built it myself from sources. Build times with 0.76 are just barely tolerable with my app. But my colleague was telling me today that he wants to do his work on a small, non-DWT test app instead of the main app because the build times are too frustrating for him. If I were forced to use the latest DSSS, I'd defnitely be trying to do whatever I could to improve the build times, including using "make" if that's what it took. Hmm... Now that dmd -v will spit out all the modules imported, it might be possible to use that to create a makefile (or a make.deps for use by a makefile) automatically. --bb

I suggest people to try rdmd out. It comes with the standard distribution and I'd want to improve it based on feedback. http://www.digitalmars.com/d/2.0/rdmd.html Andrei

atm I am not at home but I have a nice Windows popen() emulation based on windows pipes, so not exactly the same, but imo good enough. I can send you the sources when I am back in france. Or just google for popen windows pipes. would be a nice to have rdmd as windoxs too bjrn fighting with different kezbqrd lqouts
Nov 14 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BLS wrote:
 Andrei Alexandrescu Wrote:
 
 Bill Baxter wrote:
 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:
 Hello Bill,


 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb

times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

I've gone back to 0.76, which I think may have never been released. I think I built it myself from sources. Build times with 0.76 are just barely tolerable with my app. But my colleague was telling me today that he wants to do his work on a small, non-DWT test app instead of the main app because the build times are too frustrating for him. If I were forced to use the latest DSSS, I'd defnitely be trying to do whatever I could to improve the build times, including using "make" if that's what it took. Hmm... Now that dmd -v will spit out all the modules imported, it might be possible to use that to create a makefile (or a make.deps for use by a makefile) automatically. --bb

distribution and I'd want to improve it based on feedback. http://www.digitalmars.com/d/2.0/rdmd.html Andrei

atm I am not at home but I have a nice Windows popen() emulation based on windows pipes, so not exactly the same, but imo good enough. I can send you the sources when I am back in france. Or just google for popen windows pipes. would be a nice to have rdmd as windoxs too bjrn fighting with different kezbqrd lqouts

A cursory search does not yield the holy grail, so I'll be grateful if you followed up, preferably with a nicely packaged implementation :o). Thanks! Andrei
Nov 14 2008
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Andrei,

 Bill Baxter wrote:
 
 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer
 <terminal.node gmail.com> wrote:
 
 Hello Bill,
 
 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.
 
 --bb
 

build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

I've gone back to 0.76, which I think may have never been released. I think I built it myself from sources. Build times with 0.76 are just barely tolerable with my app. But my colleague was telling me today that he wants to do his work on a small, non-DWT test app instead of the main app because the build times are too frustrating for him. If I were forced to use the latest DSSS, I'd defnitely be trying to do whatever I could to improve the build times, including using "make" if that's what it took. Hmm... Now that dmd -v will spit out all the modules imported, it might be possible to use that to create a makefile (or a make.deps for use by a makefile) automatically. --bb

distribution and I'd want to improve it based on feedback. http://www.digitalmars.com/d/2.0/rdmd.html Andrei

Interesting. I never thought of rdmd for this purpose. I'll see what if it can help here. Thanks for the suggestion. :-) -JJR
Nov 14 2008
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrei Alexandrescu wrote:

 I suggest people to try rdmd out. It comes with the standard 
 distribution and I'd want to improve it based on feedback.
 
 http://www.digitalmars.com/d/2.0/rdmd.html

http://dsource.org/projects/phobos/browser/trunk/tools/rdmd.d For the portable version of rdmd you would want to replace version(linux) with version(Unix), like done for rdmd 1.0: http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/rdmd.d?view=markup --anders
Nov 15 2008
prev sibling next sibling parent Jeffrey Rennie <surferjeff excite.com> writes:
John Reimer wrote:
 Hello Bill,
 
 
 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb

Totally agree. The size is just an annoyance. But currently the build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

Naturally, for some of us, .exe size is more important. Specifically, for those of us building software that will be downloaded by users at home. But then again, I always build GUIs using native libraries--WTL on Win32 and Objective-C on Mac--so I'm likely not a DWT customer anyway.
Nov 14 2008
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Bill Baxter wrote:
...
 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.  I
 think I built it myself from sources.
 
 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.
 
 If I were forced to use the latest DSSS, I'd defnitely be trying to do
 whatever I could to improve the build times, including using "make" if
 that's what it took.
 
 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps for
 use by a makefile) automatically.
 
 --bb

I didn't notice dsss has such a large overhead, is this due to dsss parsing the whole source, or has it something to do with how it compiles applications? If it is the latter, perhaps that's amenable with some configuration? Dsss does multicore builds, that probably cancels out the overhead on my machine.
Nov 30 2008
parent John Reimer <terminal.node gmail.com> writes:
Hello lutger,

 Bill Baxter wrote:
 ...
 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.
 I think I built it myself from sources.
 
 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.
 
 If I were forced to use the latest DSSS, I'd defnitely be trying to
 do whatever I could to improve the build times, including using
 "make" if that's what it took.
 
 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps
 for use by a makefile) automatically.
 
 --bb
 

parsing the whole source, or has it something to do with how it compiles applications? If it is the latter, perhaps that's amenable with some configuration? Dsss does multicore builds, that probably cancels out the overhead on my machine.

I'm not sure what the reason is, but I imagine the re-parsing is only part of it because dsss 0.75 is actually pretty fast (compared to release 0.78). I think I remember Gregor suggesting that performance could be improved (or at least dsss could be simplified) if he had access to a new feature in the dmd compiler ("-ignore" flag: ignore unsupported pragmas). That feature was added several versions ago, but I think Gregor has been too busy to make use of it. I can't remember how using this flag could fix things for dsss, though. The answer lies somewhere in posts from earlier this year. -JJR
Nov 30 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:
 Hello Bill,


 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb

Totally agree. The size is just an annoyance. But currently the build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

Build times with the new dsss push me way past the sanity point, so I've gone back to 0.76, which I think may have never been released. I think I built it myself from sources. Build times with 0.76 are just barely tolerable with my app. But my colleague was telling me today that he wants to do his work on a small, non-DWT test app instead of the main app because the build times are too frustrating for him. If I were forced to use the latest DSSS, I'd defnitely be trying to do whatever I could to improve the build times, including using "make" if that's what it took. Hmm... Now that dmd -v will spit out all the modules imported, it might be possible to use that to create a makefile (or a make.deps for use by a makefile) automatically. --bb
Nov 13 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Bill,

 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com>
 wrote:
 
 Hello Bill,
 
 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.
 
 --bb
 

build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

I've gone back to 0.76, which I think may have never been released. I think I built it myself from sources. Build times with 0.76 are just barely tolerable with my app. But my colleague was telling me today that he wants to do his work on a small, non-DWT test app instead of the main app because the build times are too frustrating for him. If I were forced to use the latest DSSS, I'd defnitely be trying to do whatever I could to improve the build times, including using "make" if that's what it took. Hmm... Now that dmd -v will spit out all the modules imported, it might be possible to use that to create a makefile (or a make.deps for use by a makefile) automatically. --bb

Frank uses 0.75, but I can't get it to work with Tango svn... But it did appear to be much quicker than 0.78. I noticed just doing a dmd *.c on a DWT directory compiles things pretty fast... so that's why I was considering a shell script or make file. The only thing I'd miss is the installation and automatic library creation features of dsss. But I need the speed more. The dmd -v option has actually been available for quite awhile (a couple years?). "jake", a build tool Kris threw together a year or two ago, makes good use of dmd -v import list to do some blazingly fast compiles on windows. Awhile ago, I had considered porting "jake" to linux (it's C source but with win32 functions). I may have another look at doing that. DWT really needs it. -JJR
Nov 14 2008
parent reply TomD <t_demmer nospam.web.de> writes:
John Reimer Wrote:
[...]
My quickfix:
----- Snip ----
#!/bin/bash
# makemaker: create a Makefile in every subdir that contains
# .d files.
# Use like this:
# makemaker > all.mak
# and set up DC, DCSYSFLAGS, DCFLAGS, OBJEXT in the top
# Makefile
for d in `find $1 -type d`; do
    cd $d
    ls *.d >/dev/null 2>/dev/null
    if [ $? == 0 ] ; then
        rm -f Makefile
        echo "SRC=" `ls *.d` > Makefile
        echo 'OBJ=   $(SRC:.d=$(OBJEXT))' >> Makefile
        echo '%.obj: %.d' >> Makefile
        echo -e '\t $(DC) $(DCSYSFLAGS) $(DCFLAGS) -c $<' >> Makefile
        echo 'all: $(OBJ)' >> Makefile
        echo 'clean:'  >> Makefile
        echo -e '\t rm $(OBJ)' >> Makefile
        
        hasd=1
    else
        hasd=0
    fi
    cd - > /dev/null
    if [ $hasd == 1  ] ; then
        echo make -C $d all
    fi
---- snap ---
Nov 14 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello TomD,

 John Reimer Wrote:
 [...]
 My quickfix:
 ----- Snip ----
 #!/bin/bash
 # makemaker: create a Makefile in every subdir that contains
 # .d files.
 # Use like this:
 # makemaker > all.mak
 # and set up DC, DCSYSFLAGS, DCFLAGS, OBJEXT in the top
 # Makefile
 for d in `find $1 -type d`; do
 cd $d
 ls *.d >/dev/null 2>/dev/null
 if [ $? == 0 ] ; then
 rm -f Makefile
 echo "SRC=" `ls *.d` > Makefile
 echo 'OBJ=   $(SRC:.d=$(OBJEXT))' >> Makefile
 echo '%.obj: %.d' >> Makefile
 echo -e '\t $(DC) $(DCSYSFLAGS) $(DCFLAGS) -c $<' >> Makefile
 echo 'all: $(OBJ)' >> Makefile
 echo 'clean:'  >> Makefile
 echo -e '\t rm $(OBJ)' >> Makefile
 hasd=1
 else
 hasd=0
 fi
 cd - > /dev/null
 if [ $hasd == 1  ] ; then
 echo make -C $d all
 fi
 ---- snap ---

Thanks for the example. I've avoided makefiles in the past because, despite their power and flexibility, they are too complicated for what amounts to a fairly simple task in most cases. Granted, once they are created for a project, there shouldn't be much need to fiddle with them more. Anyway, I'll keep your sample above in mind if I go this route. Thanks. :) -JJR
Nov 14 2008
parent TomD <t_demmer nospam.web.de> writes:
John Reimer Wrote:
[...]
 Thanks for the example.  I've avoided makefiles in the past because, despite 
 their power and flexibility, they are too complicated for what amounts to 
 a fairly simple task in most cases.  Granted, once they are created for a 
 project, there shouldn't be much need to fiddle with them more.
 
 Anyway, I'll keep your sample above in mind if I go this route.  Thanks. :)
 
 -JJR

is just enough". The following script is the fastest way to rebuild dwt on linux: ----- #!/bin/bash DMD=/opt/dmd/bin/dmd DMDFLAGS="-debuglib=tango-base-dmd -defaultlib=tango-base-dmd" DMDFLAGS=$DMDFLAGS" -I/opt/dmd/import" DMDFLAGS=$DMDFLAGS" -version=Tango -version=Posix -L-tango-user-dmd" DMDFLAGS=$DMDFLAGS" -O -release" WBD=`pwd` DMDFLAGS="-I$WBD $DMDFLAGS" echo "Compile command:" echo $DMD $DMDFLAGS -c -op find dwt -iname \*.d | xargs $DMD $DMDFLAGS -c -op echo "done compiling, build libdwt.a" find dwt -name \*.o | xargs ar -svr libdwt.a ---- That takes 27s on my Laptop. I used to do the same directorywise, that takes about 1m15s. Looks like the best strategy for a build tool is to first grab the names of the files to recompile and then give it to one instance of dmd to compile all of them at once. Unfortunately, the -v switch does not help when invoking dmd like this. Ciao Tom
Nov 16 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Nov 16, 2008 at 6:01 PM, TomD <t_demmer nospam.web.de> wrote:
 John Reimer Wrote:
 [...]
 Thanks for the example.  I've avoided makefiles in the past because, despite
 their power and flexibility, they are too complicated for what amounts to
 a fairly simple task in most cases.  Granted, once they are created for a
 project, there shouldn't be much need to fiddle with them more.

 Anyway, I'll keep your sample above in mind if I go this route.  Thanks. :)

 -JJR

is just enough". The following script is the fastest way to rebuild dwt on linux: ----- #!/bin/bash DMD=/opt/dmd/bin/dmd DMDFLAGS="-debuglib=tango-base-dmd -defaultlib=tango-base-dmd" DMDFLAGS=$DMDFLAGS" -I/opt/dmd/import" DMDFLAGS=$DMDFLAGS" -version=Tango -version=Posix -L-tango-user-dmd" DMDFLAGS=$DMDFLAGS" -O -release" WBD=`pwd` DMDFLAGS="-I$WBD $DMDFLAGS" echo "Compile command:" echo $DMD $DMDFLAGS -c -op find dwt -iname \*.d | xargs $DMD $DMDFLAGS -c -op echo "done compiling, build libdwt.a" find dwt -name \*.o | xargs ar -svr libdwt.a ---- That takes 27s on my Laptop. I used to do the same directorywise, that takes about 1m15s. Looks like the best strategy for a build tool is to first grab the names of the files to recompile and then give it to one instance of dmd to compile all of them at once. Unfortunately, the -v switch does not help when invoking dmd like this.

This agrees with the conventional wisdom for using dsss, which is to turn the oneatatime option to off. I believe that causes dmd to be called once with all the dependent files as args. --bb
Nov 16 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Bill,

 On Sun, Nov 16, 2008 at 6:01 PM, TomD <t_demmer nospam.web.de> wrote:
 
 John Reimer Wrote:
 [...]
 Thanks for the example.  I've avoided makefiles in the past because,
 despite
 their power and flexibility, they are too complicated for what
 amounts to
 a fairly simple task in most cases.  Granted, once they are created
 for a
 project, there shouldn't be much need to fiddle with them more.
 Anyway, I'll keep your sample above in mind if I go this route.
 Thanks. :)
 
 -JJR
 

force is just enough". The following script is the fastest way to rebuild dwt on linux: ----- #!/bin/bash DMD=/opt/dmd/bin/dmd DMDFLAGS="-debuglib=tango-base-dmd -defaultlib=tango-base-dmd" DMDFLAGS=$DMDFLAGS" -I/opt/dmd/import" DMDFLAGS=$DMDFLAGS" -version=Tango -version=Posix -L-tango-user-dmd" DMDFLAGS=$DMDFLAGS" -O -release" WBD=`pwd` DMDFLAGS="-I$WBD $DMDFLAGS" echo "Compile command:" echo $DMD $DMDFLAGS -c -op find dwt -iname \*.d | xargs $DMD $DMDFLAGS -c -op echo "done compiling, build libdwt.a" find dwt -name \*.o | xargs ar -svr libdwt.a ---- That takes 27s on my Laptop. I used to do the same directorywise, that takes about 1m15s. Looks like the best strategy for a build tool is to first grab the names of the files to recompile and then give it to one instance of dmd to compile all of them at once. Unfortunately, the -v switch does not help when invoking dmd like this.

turn the oneatatime option to off. I believe that causes dmd to be called once with all the dependent files as args. --bb

An update: I'm back to using dsss successfully with acceptable build times. I followed a setup similar to Frank's and managed to install dsss 0.75 correctly such that it builds a dwt-based project in approximately 38 seconds (with -gc flag active). For debug/test builds, I avoid building the dwt library itself and simply reference the dwt directory as a source library while compiling the test project. With a slight adjustment to the etc/rebuild/dmd-tango-posix config file, I'm now content with the ease of building sample projects via dsss. Incidentally, I was originally doing all this on a linux distribution installed in a virtual machine (VirtualBox originally, then Vmware) which probably slowed the build times further. I have since moved to using colinux under Windows XP which has proved to be a delight to work under. For those interested, there are a couple of linux distribution projects that use colinux as there base. It basically allows you to run linux and linux programs full speed as a win32 service. X windows programs can run seemlessly with win32 apps by using XMing which is installed as part of the package. The apps run very fast since they are not being run inside a virtual machine! Here's the link to just one of the colinux distribtuions (based on Ubuntu, the one I am currently using): http://www.andlinux.org/ And here's a link that list a few other options: http://colinux.wikia.com/wiki/Installation_out_of_the_box You should still have a fair bit of RAM to run coLinux. I've got 1 GB on my laptop, but 2+ GB probably would be better. -JJR
Nov 29 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
John Reimer wrote:
 Hello Bill,
 
 On Sun, Nov 16, 2008 at 6:01 PM, TomD <t_demmer nospam.web.de> wrote:

 John Reimer Wrote:
 [...]
 Thanks for the example.  I've avoided makefiles in the past because,
 despite
 their power and flexibility, they are too complicated for what
 amounts to
 a fairly simple task in most cases.  Granted, once they are created
 for a
 project, there shouldn't be much need to fiddle with them more.
 Anyway, I'll keep your sample above in mind if I go this route.
 Thanks. :)

 -JJR

force is just enough". The following script is the fastest way to rebuild dwt on linux: ----- #!/bin/bash DMD=/opt/dmd/bin/dmd DMDFLAGS="-debuglib=tango-base-dmd -defaultlib=tango-base-dmd" DMDFLAGS=$DMDFLAGS" -I/opt/dmd/import" DMDFLAGS=$DMDFLAGS" -version=Tango -version=Posix -L-tango-user-dmd" DMDFLAGS=$DMDFLAGS" -O -release" WBD=`pwd` DMDFLAGS="-I$WBD $DMDFLAGS" echo "Compile command:" echo $DMD $DMDFLAGS -c -op find dwt -iname \*.d | xargs $DMD $DMDFLAGS -c -op echo "done compiling, build libdwt.a" find dwt -name \*.o | xargs ar -svr libdwt.a ---- That takes 27s on my Laptop. I used to do the same directorywise, that takes about 1m15s. Looks like the best strategy for a build tool is to first grab the names of the files to recompile and then give it to one instance of dmd to compile all of them at once. Unfortunately, the -v switch does not help when invoking dmd like this.

turn the oneatatime option to off. I believe that causes dmd to be called once with all the dependent files as args. --bb

An update: I'm back to using dsss successfully with acceptable build times. I followed a setup similar to Frank's and managed to install dsss 0.75 correctly such that it builds a dwt-based project in approximately 38 seconds (with -gc flag active). For debug/test builds, I avoid building the dwt library itself and simply reference the dwt directory as a source library while compiling the test project. With a slight adjustment to the etc/rebuild/dmd-tango-posix config file, I'm now content with the ease of building sample projects via dsss. Incidentally, I was originally doing all this on a linux distribution installed in a virtual machine (VirtualBox originally, then Vmware) which probably slowed the build times further. I have since moved to using colinux under Windows XP which has proved to be a delight to work under. For those interested, there are a couple of linux distribution projects that use colinux as there base. It basically allows you to run linux and linux programs full speed as a win32 service. X windows programs can run seemlessly with win32 apps by using XMing which is installed as part of the package. The apps run very fast since they are not being run inside a virtual machine! Here's the link to just one of the colinux distribtuions (based on Ubuntu, the one I am currently using): http://www.andlinux.org/ And here's a link that list a few other options: http://colinux.wikia.com/wiki/Installation_out_of_the_box You should still have a fair bit of RAM to run coLinux. I've got 1 GB on my laptop, but 2+ GB probably would be better. -JJR

Thanks for introducing me to coLinux! Sadly, no 64-bit support yet, otherwise I would be installing it as I write this. That's a very awesome project.
Nov 29 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Robert,

 

otherwise I would be installing it as I write this. That's a very awesome project.

Yep, no problem. I don't know if 64-bit is in the pipe for colinux, but that would certainly make it more awesome for sure :-). Probably something to keep one's eye on. The only slight frustration right now for me is that I failed to get eclipse 3.4 working, so I can't put descent to good use. ;) I don't know what the problem is, but it might have something to do with my Java configuration. Oh well. -JJR
Nov 30 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
John Reimer wrote:
 Hello Robert,
 

otherwise I would be installing it as I write this. That's a very awesome project.

Yep, no problem. I don't know if 64-bit is in the pipe for colinux, but that would certainly make it more awesome for sure :-). Probably something to keep one's eye on. The only slight frustration right now for me is that I failed to get eclipse 3.4 working, so I can't put descent to good use. ;) I don't know what the problem is, but it might have something to do with my Java configuration. Oh well. -JJR

It's impossible to run Eclipse under Windows and save to the linux drive (mounted under Windows, obviously)?
Nov 30 2008
parent John Reimer <terminal.node gmail.com> writes:
Hello Robert,

 John Reimer wrote:
 
 Hello Robert,
 
 Thanks for introducing me to coLinux! Sadly, no 64-bit support yet,
 otherwise I would be installing it as I write this. That's a very
 awesome project.
 

but that would certainly make it more awesome for sure :-). Probably something to keep one's eye on. The only slight frustration right now for me is that I failed to get eclipse 3.4 working, so I can't put descent to good use. ;) I don't know what the problem is, but it might have something to do with my Java configuration. Oh well. -JJR

drive (mounted under Windows, obviously)?

Hmm... Actually, it should be possible in a different way. During the install, colinux gets you to choose a windows directory to mount so that you have direct access (both read and write, if you want) from within colinux. Kind of the opposite of what you are suggesting, but maybe I can make use of that somehow (although, I'm not sure linux will like building a project from the mounted ntfs partition). Even if I could access the linux partition directly, though, I'm not sure it would be very safe to have write access to an ext3-fs from windows. I'll have to think about this one. Would be nice if I could just get Eclipse working. :-) In the meantime, it's easy enough just to use some other editor (gedit for now) along with the commandline. -JJR
Nov 30 2008
prev sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Fri, Nov 14, 2008 at 10:46 AM, Jeffrey Rennie <surferjeff excite.com> wrote:
 John Reimer wrote:
 Hello Bill,


 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb

Totally agree. The size is just an annoyance. But currently the build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

Naturally, for some of us, .exe size is more important. Specifically, for those of us building software that will be downloaded by users at home. But then again, I always build GUIs using native libraries--WTL on Win32 and Objective-C on Mac--so I'm likely not a DWT customer anyway.

I'm pretty sure DWT uses the underlying native GUI APIs. At least it looked that way when I saw it demonstrated.
Nov 14 2008
parent John Reimer <terminal.node gmail.com> writes:
Hello Jarrett,

 On Fri, Nov 14, 2008 at 10:46 AM, Jeffrey Rennie
 <surferjeff excite.com> wrote:
 
 John Reimer wrote:
 
 Hello Bill,
 
 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.
 
 --bb
 

build times are pretty bad. Recently, I've been frustrating over this especially while working on the Browser port. Everytime I want to test a fix, I have to recompile... which takes ages. This seems to be partly due to the dsss dependency (recent version is sloooow). I've been thinking of adding some sort of shell script or "make" file to see if this can be improved... at least for sanities' sake. :-( -JJR

Specifically, for those of us building software that will be downloaded by users at home. But then again, I always build GUIs using native libraries--WTL on Win32 and Objective-C on Mac--so I'm likely not a DWT customer anyway.

looked that way when I saw it demonstrated.

Yes, it does so on all platforms (GTK on Linux, win32/64 API on Windows, Cocoa on Mac). That's the main principle behind SWT and the deciding factor for us choosing to port it :). This is what differentiates it from other Java frameworks like Swing. In D, the size appears to be a result of both the SWT design (and shear size of the project) and the compiler/linker implementation. -JJR
Nov 14 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Nov 13, 2008 at 10:41 PM, huurd <hurd 163.com> wrote:
 the disassemble file is a lot repeat like "ADD [EAX],AL";

That's just 0s.
Nov 13 2008
prev sibling parent yidabu <yidabu.spam gmail.com> writes:
On Fri, 14 Nov 2008 02:14:23 +0000 (UTC)
John Reimer <terminal.node gmail.com> wrote:

 Hello huurd,
 
 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size
 is 800kb.
 
 exe file appears to be a lot of meaningless repeat, how to remove it?
 

22M is distastefully huge for a hello world example using dwt and dwtx :(. Like other's suggested, maybe debug info is getting compiled in due to a -g switch. The file size still may end up being several megabytes, though, even without the debug info. This is more of an annoyance, than a hindrance. DWT has a lot to offer; so most people end up coping with the size issue, especially if they know they can use something like upx to squeeze things tight. I can't exactly remember what the cause of this is, but I think it has something to do with scads of "hidden" D symbols (moduleinfo?) produced by the D compiler for projects that have a combination of (1) tons of modules and (2) many interdependencies amongst modules such that even a small project ends up linking in ALL (or nearly so) classes from the framework. This, unfortunately, is one of DWT's weaknesses. I wish the language could help DWT by fixing that, but I don't know if that is possible. Other alternatives that might help reduce the problem (I think) is integrating multiple modules into one file...but that tends to hinder the whole idea of organization and namespace clarity. If DWT were to do this, it would also break import compatibility with SWT. There are a few reasons why this approach is not desirable. But I hear you. I really don't like unnecessary bloat either. It would be great if we had some super smart tools that could pair things down a bit. -JJR

I use dsss 0.75 to build static dwt-win library. use dmd + gnu make to build binary. It's small binary size. only issue is it takes more times to build a static library. -- yidabu <yidabu.spam gmail.com> http://www.dsource.org/projects/dwin D -(D Chinese): http://www.d-programming-language-china.org/ http://bbs.d-programming-language-china.org/ http://dwin.d-programming-language-china.org/ http://scite4d.d-programming-language-china.org/
Nov 14 2008