[Issue 1166] DMD doesn't support UTF encoded response files
https://issues.dlang.org/show_bug.cgi?id=1166 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #3 from RazvanN --- Compiling the code in the .rsp file now yields: onlineapp.d: Error: module `onlineapp` source file must start with BOM or ASCII character, not \xC2 Closing as fixed. --
[Issue 4928] New: [patch] RDMD mistakes object, library and response files for the program file.
http://d.puremagic.com/issues/show_bug.cgi?id=4928 Summary: [patch] RDMD mistakes object, library and response files for the program file. Product: D Version: D1 D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: cbkbbej...@mailinator.com --- Comment #0 from Nick Sabalausky cbkbbej...@mailinator.com 2010-09-23 18:29:20 PDT --- Created an attachment (id=768) Patch against rdmd r1400 rdmd extraStuff.obj main.d Expected: chdir . dmd extraStuff.obj -v -o- main.d main.d.deps Actual: chdir . dmd -v -o- extraStuff.obj.d extraStuff.obj.d.deps -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4928] [patch] RDMD mistakes object, library and response files for the program file.
http://d.puremagic.com/issues/show_bug.cgi?id=4928 --- Comment #2 from Nick Sabalausky cbkbbej...@mailinator.com 2010-09-23 18:33:13 PDT --- Ditto for .def files. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4928] [patch] RDMD mistakes object, library and response files for the program file.
http://d.puremagic.com/issues/show_bug.cgi?id=4928 --- Comment #1 from Nick Sabalausky cbkbbej...@mailinator.com 2010-09-23 18:31:31 PDT --- Note that problem also occurs if extraStuff.obj is a .o, .lib, .a, or @extraStuff.txt. The patch fixes all of these cases. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: Build systems with D support [was: Response files]
Leandro Lucarella llu...@gmail.com wrote in message news:20090323192000.ga23...@burns.springfield.home... Leandro Lucarella, el 23 de marzo a las 13:31 me escribiste: And guess what? It even support D =) http://waf.googlecode.com/svn/trunk/demos/d/ It looks like AAP support D too =) http://www.a-a-p.org/exec/ref-modules.html#id2686506 It's nice new build system support D. It seems that the lack-of-tools situation is finally getting better =) FWIW, AAP has had D support for a long time.
Re: Response files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bright wrote: Georg Wrede wrote: half jokingly Young people tend to always choose the absolutely best, while older people value stability and longevity of tools. So, yesterday the best was SCons, today it's AAP, what's it gonna be tomorrow? Old people prefer something like make, that's been around for some time, and which will still be around in the future. / Yeah, I'm old. I still don't use an IDE g. Neither do I. But then, neither SCons, nor AAP, nor waf, nor cmake are IDEs gg/. Jerome - -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknJODAACgkQd0kWM4JG3k9QPACeJtdkO9koz9bhYVm0DfiYZC0w 2cAAn3LGWDl2ytNm2MB5O9k08FfzI/Vz =oyLR -END PGP SIGNATURE-
Re: Response files
Georg Wrede, el 22 de marzo a las 17:51 me escribiste: So, yesterday the best was SCons, today it's AAP, what's it gonna be tomorrow? Waf[1]? No, really, I just discover it today =) What I always hated from scons (and the reason I stopped using it) is it was *sloow* (I don't know if it improved). So today, because of this discussion, I hit this page with some benchmarks about build systems: http://psycle.svn.sourceforge.net/viewvc/psycle/branches/bohan/wonderbuild/benchmarks/time.xml Waf seems to be a good candidate, this are the main features: - Easy to use: Waf configuration files are written in the mainstream scripting language Python - Easy to install and to distribute: Waf fits entirely in a single 75KB redistributable file which does not require any installation to run - Portable: Waf only depends on Python which is ported onto most operating systems - Reliable: Waf uses hash-based dependency calculation dependencies to compute the targets to rebuild - User-friendly: The output can be displayed in colors, filtered, displayed with progress bars or output all the commands that get executed - Documented: The Waf book sums up the essential concepts - Flexible: Because Waf has a carefully designed object oriented architecture it is very easy to add new features - Fast: Because of its carefully designed architecture, Waf is able to distribute the jobs on multi-core hardware (-j), it is able to reuse targets compiled already (ccache), and its runtime footprint is pretty small compared to other build tools - Broad support for languages and tools: Waf is already used for C, C++, C#, D, java, ocaml, python project, and provides various tools for processing docbook, man pages, intltool, msgfmt The only feature I don't appreciate much (as of scons) is that build files are written in Python (even when I lve Python, I don't think it's the best choice for build files). And guess what? It even support D =) http://waf.googlecode.com/svn/trunk/demos/d/ [1] http://code.google.com/p/waf/ -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: Response files
Leandro Lucarella wrote: Walter Bright, el 21 de marzo a las 20:07 me escribiste: Andrei Alexandrescu wrote: .o on Linux, .obj on Windows. OBJSUFFIX_win32 = .obj OBJSUFFIX_linux = .o ... OS = linux ... ... file$(OBJSUFFIX_$(OS)) ... I hadn't thought of using macros to generate macros. It's a good idea. I think it's easier and cleaner to use conditionals: OS = linux ifeq ($(OS),linux) OBJSUFFIX = .o else ifeq ($(OS),win32) OBJSUFFIX = .obj endif ... file$(OBJSUFFIX) ... Yah, yet it turns out it's easier and cleaner the other way around when you generate entries with define and eval: define GENERATE # $1 is OS, $2 is the build ... endef $(eval $(foreach B,debug release, $(foreach S,posix win32, $(call GENERATE,$S,$B This way in one shot you generate debug and release versions for win32 and posix. (Note that I compile for win32 on linux thwough wine). Andrei
Build systems with D support [was: Response files]
Leandro Lucarella, el 23 de marzo a las 13:31 me escribiste: And guess what? It even support D =) http://waf.googlecode.com/svn/trunk/demos/d/ It looks like AAP support D too =) http://www.a-a-p.org/exec/ref-modules.html#id2686506 It's nice new build system support D. It seems that the lack-of-tools situation is finally getting better =) It should be nice to have a listing of tools that work well with D in the official website. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: Build systems with D support [was: Response files]
Leandro Lucarella wrote: Leandro Lucarella, el 23 de marzo a las 13:31 me escribiste: And guess what? It even support D =) http://waf.googlecode.com/svn/trunk/demos/d/ It looks like AAP support D too =) http://www.a-a-p.org/exec/ref-modules.html#id2686506 It's nice new build system support D. It seems that the lack-of-tools situation is finally getting better =) Cool! It should be nice to have a listing of tools that work well with D in the official website. This kind of thing is better done through the D wiki, as experience shows that such things in the D pages get rapidly out of date, and people have to wait for me to fix them.
Re: Build systems with D support [was: Response files]
On Mon, Mar 23, 2009 at 6:15 PM, Walter Bright newshou...@digitalmars.com wrote: Leandro Lucarella wrote: Leandro Lucarella, el 23 de marzo a las 13:31 me escribiste: And guess what? It even support D =) http://waf.googlecode.com/svn/trunk/demos/d/ It looks like AAP support D too =) http://www.a-a-p.org/exec/ref-modules.html#id2686506 It's nice new build system support D. It seems that the lack-of-tools situation is finally getting better =) Cool! It should be nice to have a listing of tools that work well with D in the official website. This kind of thing is better done through the D wiki, as experience shows that such things in the D pages get rapidly out of date, and people have to wait for me to fix them. For what it's worth, most of the D wiki is incredibly out-of-date too. I just don't think there's enough manpower to go around to maintain it.
Re: Response files
Leandro Lucarella wrote: Georg Wrede escribiste: So, yesterday the best was SCons, today it's AAP, what's it gonna be tomorrow? Waf[1]? ... And guess what? It even support D =) Oh, ok. And the day after tomorrow? (Sorry, couldn't resist. :-) )
Re: Build systems with D support [was: Response files]
Jarrett Billingsley wrote: For what it's worth, most of the D wiki is incredibly out-of-date too. I just don't think there's enough manpower to go around to maintain it. Anyone can update it!
Re: Build systems with D support [was: Response files]
On Mon, Mar 23, 2009 at 6:53 PM, Walter Bright newshou...@digitalmars.com wrote: Jarrett Billingsley wrote: For what it's worth, most of the D wiki is incredibly out-of-date too. I just don't think there's enough manpower to go around to maintain it. Anyone can update it! You noticed my comment about not enough manpower, I hope!
Re: Build systems with D support [was: Response files]
Jarrett Billingsley wrote: On Mon, Mar 23, 2009 at 6:53 PM, Walter Bright newshou...@digitalmars.com wrote: Jarrett Billingsley wrote: For what it's worth, most of the D wiki is incredibly out-of-date too. I just don't think there's enough manpower to go around to maintain it. Anyone can update it! You noticed my comment about not enough manpower, I hope! Sure, but it's amazing what a single person can do if they just keep picking at something that interests them.
Re: Response files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bright wrote: Georg Wrede wrote: 'Round here we say maassa maan tavalla, which is probably something like When in Rome, do like the Romans do. Makefiles aren't just a C(++) thing. Unix has a culture of its own, Windows (I wouldn't say have a culture, but still) does it another way. So do we import the Unix way to Windows or the other way around? I'd go with the Romans in Rome. If there were a vote (outside of this NG!!) with D users, probably there are more folks who write in D /and/ in C or another language /on their own/ OS, than folks who write D apps (big enough to need makefiles) for both Windows and Linux. There is no standard for makefiles, I've run across dozens of different make programs that use different syntax and have different extensions. So, if you're going to have the same makefile across systems, you have to start with finding a make program that is fairly identical across those systems. Then you have the \ vs / problems. Some people assure me that Windows now works flawlessly with /, but that simply isn't so. I keep running into odd cases where it doesn't, so I don't use / on Windows. File name case sensitivity differs. The command line utilities called by makefiles differ in their names, switches, and how they work. .o on Linux, .obj on Windows. nothing on Linux, .exe on Windows. .a on Linux, .lib on Windows. It just goes on and on. You could try and parameterize all of it, but then the makefile becomes an inscrutable mess. You could have scripts generate makefiles, embed scripts in the makefiles, etc., but is this really worthwhile? It's just a makefile. I spend almost zero time on them. I like them simple even if that means they're more verbose. Or use a build system that abstracts all the differences for you. I use SCons all the time to write software that works on both Linux and Windows and I have none of the problems you describe: - SCons is released for both Linux and Windows (and MacOS) and is the same on all platforms; - All my file names are in lower case, ever (this has nothing to do with the make tool btw); - SCons uses '/' as the path delimiter everywhere and translates them appropriately; - In SCons, you only specify the core file name and SCons adds the required prefix and suffix (eg object = object.o/object.obj, program = program/program.exe, library = liblibrary.a/library.lib); - Plus SCons is able to do parallel compilations which make isn't really (the '-j' option is broken on all the make implementations I know). All the complexity and the parametrization is handled internally by SCons so the makefiles are both simple *and* terse ;) Jerome PS: Though I've never used it, cmake is supposed to offer most of the same benefits as SCons. - -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknF6lgACgkQd0kWM4JG3k9KfQCdGc1BQJiuWPimuX13fz4dC8sT kTkAnjE58mPisayr+EgE9FDWhFvPFD2f =uP45 -END PGP SIGNATURE-
Re: Response files
Jérôme M. Berger jeber...@free.fr wrote in message news:gq4pop$154...@digitalmars.com... Walter Bright wrote: Georg Wrede wrote: 'Round here we say maassa maan tavalla, which is probably something like When in Rome, do like the Romans do. Makefiles aren't just a C(++) thing. Unix has a culture of its own, Windows (I wouldn't say have a culture, but still) does it another way. So do we import the Unix way to Windows or the other way around? I'd go with the Romans in Rome. If there were a vote (outside of this NG!!) with D users, probably there are more folks who write in D /and/ in C or another language /on their own/ OS, than folks who write D apps (big enough to need makefiles) for both Windows and Linux. There is no standard for makefiles, I've run across dozens of different make programs that use different syntax and have different extensions. So, if you're going to have the same makefile across systems, you have to start with finding a make program that is fairly identical across those systems. Then you have the \ vs / problems. Some people assure me that Windows now works flawlessly with /, but that simply isn't so. I keep running into odd cases where it doesn't, so I don't use / on Windows. File name case sensitivity differs. The command line utilities called by makefiles differ in their names, switches, and how they work. .o on Linux, .obj on Windows. nothing on Linux, .exe on Windows. .a on Linux, .lib on Windows. It just goes on and on. You could try and parameterize all of it, but then the makefile becomes an inscrutable mess. You could have scripts generate makefiles, embed scripts in the makefiles, etc., but is this really worthwhile? It's just a makefile. I spend almost zero time on them. I like them simple even if that means they're more verbose. Or use a build system that abstracts all the differences for you. I use SCons all the time to write software that works on both Linux and Windows and I have none of the problems you describe: - SCons is released for both Linux and Windows (and MacOS) and is the same on all platforms; - All my file names are in lower case, ever (this has nothing to do with the make tool btw); - SCons uses '/' as the path delimiter everywhere and translates them appropriately; - In SCons, you only specify the core file name and SCons adds the required prefix and suffix (eg object = object.o/object.obj, program = program/program.exe, library = liblibrary.a/library.lib); - Plus SCons is able to do parallel compilations which make isn't really (the '-j' option is broken on all the make implementations I know). All the complexity and the parametrization is handled internally by SCons so the makefiles are both simple *and* terse ;) Yea, I was going to mention that, too. As far as I'm concerned *make is the same sort of undead unholy relic as C++. Ie, They've served their use, but these days they're terrible anachronisms that just need to be allowed to finally die. SCons absolutely *kills* make, and last I looked, AAP was even better than SCons (IMO). Not to get into an AAP vs SCons debate or anything, but my point is, with all the stuff out there that's so much better than *make, there's really not much reason beyond pure inertia and ignorance of the alternatives to keep holding onto it.
Re: Response files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Sabalausky wrote: Yea, I was going to mention that, too. As far as I'm concerned *make is the same sort of undead unholy relic as C++. Ie, They've served their use, but these days they're terrible anachronisms that just need to be allowed to finally die. SCons absolutely *kills* make, and last I looked, AAP was even better than SCons (IMO). Not to get into an AAP vs SCons debate or anything, but my point is, with all the stuff out there that's so much better than *make, there's really not much reason beyond pure inertia and ignorance of the alternatives to keep holding onto it. I don't know AAP. Do you have a link? A quick look on google and freshmeat didn't return anything useful... Jerome - -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknGFo8ACgkQd0kWM4JG3k/C3gCePrhQnhCudgr2x69/esmR58bM HngAmwbscbfRd7cIrJpb94BTCVeQWWCf =gj5+ -END PGP SIGNATURE-
Re: Response files
Andrei Alexandrescu wrote: Walter Bright wrote: Andrei Alexandrescu wrote: .o on Linux, .obj on Windows. OBJSUFFIX_win32 = .obj OBJSUFFIX_linux = .o ... OS = linux ... ... file$(OBJSUFFIX_$(OS)) ... This is so totally neat! I hadn't thought of using macros to generate macros. It's a good idea. I confess I also hadn't until the third iteration of the Phobos makefile. Yeah. In hindsight, any moron could claim this is trivial and obvious. But alas, it takes a thousand morons a thousand years to come up with things like this. D is blessed with several very gifted people, and we already run circles around C++. I can't even begin to imagine what D4 willl look like!! :-)
Re: Response files
Jérôme M. Berger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Sabalausky wrote: Yea, I was going to mention that, too. As far as I'm concerned *make is the same sort of undead unholy relic as C++. Ie, They've served their use, but these days they're terrible anachronisms that just need to be allowed to finally die. SCons absolutely *kills* make, and last I looked, AAP was even better than SCons (IMO). Not to get into an AAP vs SCons debate or anything, but my point is, with all the stuff out there that's so much better than *make, there's really not much reason beyond pure inertia and ignorance of the alternatives to keep holding onto it. I don't know AAP. Do you have a link? A quick look on google and freshmeat didn't return anything useful... http://www.a-a-p.org/
Re: Response files
Georg Wrede georg.wr...@iki.fi wrote in message news:gq5mp9$2ht...@digitalmars.com... Nick Sabalausky wrote: Jérôme M. Berger jeber...@free.fr wrote: Or use a build system that abstracts all the differences for you. I use SCons all the time to write software that works on both Linux and Windows and I have none of the problems you describe: - SCons is released for both Linux and Windows (and MacOS) and is the same on all platforms; - All my file names are in lower case, ever (this has nothing to do with the make tool btw); - SCons uses '/' as the path delimiter everywhere and translates them appropriately; - In SCons, you only specify the core file name and SCons adds the required prefix and suffix (eg object = object.o/object.obj, program = program/program.exe, library = liblibrary.a/library.lib); - Plus SCons is able to do parallel compilations which make isn't really (the '-j' option is broken on all the make implementations I know). All the complexity and the parametrization is handled internally by SCons so the makefiles are both simple *and* terse ;) Yea, I was going to mention that, too. As far as I'm concerned *make is the same sort of undead unholy relic as C++. Ie, They've served their use, but these days they're terrible anachronisms that just need to be allowed to finally die. SCons absolutely *kills* make, and last I looked, AAP was even better than SCons (IMO). Not to get into an AAP vs SCons debate or anything, but my point is, with all the stuff out there that's so much better than *make, there's really not much reason beyond pure inertia and ignorance of the alternatives to keep holding onto it. half jokingly Young people tend to always choose the absolutely best, while older people value stability and longevity of tools. So, yesterday the best was SCons, today it's AAP, what's it gonna be tomorrow? Old people prefer something like make, that's been around for some time, and which will still be around in the future. / Yes, it's not /the/ best. But then one doesn't have to learn a new system every six months just to keep with the best. Heh, very true. Of course, both sides could learn a bit from the other. Sometimes the newest/fanciest/most-popular has loads of drawbacks that the kids just don't have the experience to notice, and sometimes those more experienced end up blinded to things that may very well be true improvements. My most advanced PC here is a 1.7GHz Celeron. It does what I need it to do, and I'm happy with it. Lately I've found myself shaking my head at the young-uns these days that feed hundreds of dollars into their rigs annually just so they can play the latest games sitting at some desk instead of a nice comfy living room couch and TV. And then they get into software development and wind up inadvertently (or even deliberately) targeting their own super-powered systems and wind up creating the world's biggest bloatware. (And don't even get me started on iPods, tricked out cars and the current generation of gaming consoles.) But as far as *make vs the newer make-replacements, I just got fed up *make years ago in very much the same way I got fed up with C++. So I was looking for replacements and found the D language as well as SCons and AAP (Ok, so technically it's A-A-P, but dagnabbit, I'm gonna call it AAP in just the same crotchety way I spell Haxe with a lower-case x and pronounce it Hacks instead of Hex).
Re: Response files
Georg Wrede wrote: half jokingly Young people tend to always choose the absolutely best, while older people value stability and longevity of tools. So, yesterday the best was SCons, today it's AAP, what's it gonna be tomorrow? Old people prefer something like make, that's been around for some time, and which will still be around in the future. / Yeah, I'm old. I still don't use an IDE g.
Re: Response files
Nick Sabalausky wrote: Heh, very true. Of course, both sides could learn a bit from the other. Sometimes the newest/fanciest/most-popular has loads of drawbacks that the kids just don't have the experience to notice, and sometimes those more experienced end up blinded to things that may very well be true improvements. Of course! Any good dev team has a mix of the old geezers and the young whippersnappers. My most advanced PC here is a 1.7GHz Celeron. It does what I need it to do, and I'm happy with it. Lately I've found myself shaking my head at the young-uns these days that feed hundreds of dollars into their rigs annually just so they can play the latest games sitting at some desk instead of a nice comfy living room couch and TV. And then they get into software development and wind up inadvertently (or even deliberately) targeting their own super-powered systems and wind up creating the world's biggest bloatware. (And don't even get me started on iPods, tricked out cars and the current generation of gaming consoles.) I get a laugh out of the silly little cars with fake add-on spoilers, racing steering wheels and fart exhaust systems. When I was 15, a friend of mine got his first car, a $600 beat up '67 Mustang with a big V8 in it. He took me for a ride and floored it. It was like being launched off an aircraft carrier. I was hooked for life. You kids today have no idea g. http://www.youtube.com/watch?v=ljIA2-Y9HQkfeature=related But as far as *make vs the newer make-replacements, I just got fed up *make years ago in very much the same way I got fed up with C++. So I was looking for replacements and found the D language as well as SCons and AAP (Ok, so technically it's A-A-P, but dagnabbit, I'm gonna call it AAP in just the same crotchety way I spell Haxe with a lower-case x and pronounce it Hacks instead of Hex). I keep seeing that as AARP, the outfit that has started sending me letters to get me to sign up :-(
Re: Response files
Hello Walter, I keep seeing that as AARP, the outfit that has started sending me letters to get me to sign up :-( That says nothing. I know of people who get those who can't even vote or drink yet.
Re: Response files
Walter Bright Wrote: Frank Benoit wrote: DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. The windows response files date back to the problem DOS/Windows had with only a very short command line length was allowed. So the arguments were put into a file instead. It's probably a good idea to do it for Linux, too. Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing.
Re: Response files
Jason House schrieb: Walter Bright Wrote: Frank Benoit wrote: DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. The windows response files date back to the problem DOS/Windows had with only a very short command line length was allowed. So the arguments were put into a file instead. It's probably a good idea to do it for Linux, too. Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing. Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ?
Re: Response files
Jason House schrieb: Walter Bright Wrote: Frank Benoit wrote: DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. The windows response files date back to the problem DOS/Windows had with only a very short command line length was allowed. So the arguments were put into a file instead. It's probably a good idea to do it for Linux, too. Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing. Even in cygwin, there seems to be a 32k limit on the command line. On Linux you can find out that limit with getconf ARG_MAX (=2097152 on my linux box) This seems to be enough, however, 32k/64k are not. There is a related bug, because the dmd response file workaround is not working with 64k, see http://d.puremagic.com/issues/show_bug.cgi?id=2705
Re: Response files
Frank Benoit Wrote: [...] This seems to be enough, however, 32k/64k are not. There is a related bug, because the dmd response file workaround is not working with 64k, see http://d.puremagic.com/issues/show_bug.cgi?id=2705 Just out of curiosity: With which kind of project do you hit this limit? Ciao Tom
Re: Response files
Jason House wrote: Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing. gcc already supports it. There's apparently a demand for it.
Re: Response files
Frank Benoit wrote: Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ? I use different makefiles for Windows, Linux, and OSX. It's easier than tearing my few strands of hair out trying to figure out how to remove system differences.
Re: Response files
Walter Bright schrieb: Frank Benoit wrote: Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ? I use different makefiles for Windows, Linux, and OSX. It's easier than tearing my few strands of hair out trying to figure out how to remove system differences. Right, this is because of such stuff. With dmd acting the same, it would be one step easier. On the other hand, separated build scripts are against DRY.
Re: Response files
Jason House jason.james.ho...@gmail.com wrote in message news:gq2dv9$2vn...@digitalmars.com... Walter Bright Wrote: Frank Benoit wrote: DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. The windows response files date back to the problem DOS/Windows had with only a very short command line length was allowed. So the arguments were put into a file instead. It's probably a good idea to do it for Linux, too. Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing. Sometimes command lines get too long to keep typing (obviously). You *could* solve that with a shell/batch script, but then that would be specific to a particular shell/OS. As long as the app you're using is reasonably cross-platform, then a response file is completely shell/OS-agnostic. Response files may have originated as a workaround, but that doesn't mean they didn't turn out to have additional benefits.
Re: Response files
Walter Bright wrote: Frank Benoit wrote: Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ? I use different makefiles for Windows, Linux, and OSX. It's easier than tearing my few strands of hair out trying to figure out how to remove system differences. ...NOT. Andrei
Re: Response files
Andrei Alexandrescu wrote: Walter Bright wrote: Frank Benoit wrote: Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ? I use different makefiles for Windows, Linux, and OSX. It's easier than tearing my few strands of hair out trying to figure out how to remove system differences. ...NOT. Well... that's a bit D centric. :-) 'Round here we say maassa maan tavalla, which is probably something like When in Rome, do like the Romans do. Makefiles aren't just a C(++) thing. Unix has a culture of its own, Windows (I wouldn't say have a culture, but still) does it another way. So do we import the Unix way to Windows or the other way around? I'd go with the Romans in Rome. If there were a vote (outside of this NG!!) with D users, probably there are more folks who write in D /and/ in C or another language /on their own/ OS, than folks who write D apps (big enough to need makefiles) for both Windows and Linux.
Re: Response files
Georg Wrede wrote: 'Round here we say maassa maan tavalla, which is probably something like When in Rome, do like the Romans do. Makefiles aren't just a C(++) thing. Unix has a culture of its own, Windows (I wouldn't say have a culture, but still) does it another way. So do we import the Unix way to Windows or the other way around? I'd go with the Romans in Rome. If there were a vote (outside of this NG!!) with D users, probably there are more folks who write in D /and/ in C or another language /on their own/ OS, than folks who write D apps (big enough to need makefiles) for both Windows and Linux. There is no standard for makefiles, I've run across dozens of different make programs that use different syntax and have different extensions. So, if you're going to have the same makefile across systems, you have to start with finding a make program that is fairly identical across those systems. Then you have the \ vs / problems. Some people assure me that Windows now works flawlessly with /, but that simply isn't so. I keep running into odd cases where it doesn't, so I don't use / on Windows. File name case sensitivity differs. The command line utilities called by makefiles differ in their names, switches, and how they work. .o on Linux, .obj on Windows. nothing on Linux, .exe on Windows. .a on Linux, .lib on Windows. It just goes on and on. You could try and parameterize all of it, but then the makefile becomes an inscrutable mess. You could have scripts generate makefiles, embed scripts in the makefiles, etc., but is this really worthwhile? It's just a makefile. I spend almost zero time on them. I like them simple even if that means they're more verbose.
Re: Response files
Walter Bright wrote: Georg Wrede wrote: 'Round here we say maassa maan tavalla, which is probably something like When in Rome, do like the Romans do. Makefiles aren't just a C(++) thing. Unix has a culture of its own, Windows (I wouldn't say have a culture, but still) does it another way. So do we import the Unix way to Windows or the other way around? I'd go with the Romans in Rome. If there were a vote (outside of this NG!!) with D users, probably there are more folks who write in D /and/ in C or another language /on their own/ OS, than folks who write D apps (big enough to need makefiles) for both Windows and Linux. There is no standard for makefiles, I've run across dozens of different make programs that use different syntax and have different extensions. So, if you're going to have the same makefile across systems, you have to start with finding a make program that is fairly identical across those systems. Then you have the \ vs / problems. Some people assure me that Windows now works flawlessly with /, but that simply isn't so. I keep running into odd cases where it doesn't, so I don't use / on Windows. File name case sensitivity differs. The command line utilities called by makefiles differ in their names, switches, and how they work. dmd's flags are the same. Other than that, you only need to configure how files are deleted and how the C compiler is invoked. .o on Linux, .obj on Windows. OBJSUFFIX_win32 = .obj OBJSUFFIX_linux = .o ... OS = linux ... ... file$(OBJSUFFIX_$(OS)) ... nothing on Linux, .exe on Windows. See above. .a on Linux, .lib on Windows. See above. It just goes on and on. No. At some point it stops and you are gained by understanding where OS matters for your product and how. You could try and parameterize all of it, but then the makefile becomes an inscrutable mess. You could have scripts generate makefiles, embed scripts in the makefiles, etc., but is this really worthwhile? It's just a makefile. I spend almost zero time on them. I like them simple even if that means they're more verbose. This is because you don't really need to. I work on Phobos a fair amount, and I don't want to update four-odd places whenever I add a module. There is something to be said about once and only once. I've overhauled Phobos' makefile twice, and every time I've been gained by it. And again this brings a basic disagreement I have about making a hodge-podge of particular cases instead of searching the higher ground of proper abstraction. More code in makefiles doesn't necessarily improve things quite a lot. druntime has a lot of makefiles; apparently every single blessed thing has a makefile dedicated to it. But that complicates things without benefit. Andrei
Re: Response files
Andrei Alexandrescu wrote: More code in makefiles doesn't necessarily improve things quite a lot. druntime has a lot of makefiles; apparently every single blessed thing has a makefile dedicated to it. But that complicates things without benefit. In theory, each thing in druntime with a makefile is actually a standalone project, but since they're built together for the current distribution I agree it's overcomplicated. Regarding DM's make program, I'd be happy if it simply accepted rules with wildcards (ie. %.o : %.d). That would eliminate basically all the differences between the Win32 and Posix makefiles in druntime.
Re: Response files
Andrei Alexandrescu wrote: .o on Linux, .obj on Windows. OBJSUFFIX_win32 = .obj OBJSUFFIX_linux = .o ... OS = linux ... ... file$(OBJSUFFIX_$(OS)) ... I hadn't thought of using macros to generate macros. It's a good idea.
Re: Response files
Walter Bright wrote: Andrei Alexandrescu wrote: .o on Linux, .obj on Windows. OBJSUFFIX_win32 = .obj OBJSUFFIX_linux = .o ... OS = linux ... ... file$(OBJSUFFIX_$(OS)) ... I hadn't thought of using macros to generate macros. It's a good idea. I confess I also hadn't until the third iteration of the Phobos makefile. Andrei
Response files
DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. Instead a build mechanism needs to handle dmd in a special way on linux. cat rsp | xargs dmd Would be nice, if both can be used in the same way.
Re: Response files
Frank Benoit wrote: DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. The windows response files date back to the problem DOS/Windows had with only a very short command line length was allowed. So the arguments were put into a file instead. It's probably a good idea to do it for Linux, too.
