www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Response files

reply Frank Benoit <keinfarbton googlemail.com> writes:
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.
Mar 20 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 20 2009
parent reply Jason House <jason.james.house gmail.com> writes:
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.
Mar 21 2009
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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 ?
Mar 21 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 21 2009
next sibling parent Frank Benoit <keinfarbton googlemail.com> writes:
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.
Mar 21 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 21 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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.
Mar 21 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 21 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 21 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
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.
Mar 21 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 21 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 21 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
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!! :-)
Mar 22 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
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) ... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Mar 23 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 ... 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
Mar 23 2009
prev sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----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:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknF6lgACgkQd0kWM4JG3k9KfQCdGc1BQJiuWPimuX13fz4dC8sT kTkAnjE58mPisayr+EgE9FDWhFvPFD2f =uP45 -----END PGP SIGNATURE-----
Mar 22 2009
parent reply "Nick Sabalausky" <a a.a> writes:
""Jérôme M. Berger"" <jeberger free.fr> wrote in message 
news:gq4pop$154r$1 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.
Mar 22 2009
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
-----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:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknGFo8ACgkQd0kWM4JG3k/C3gCePrhQnhCudgr2x69/esmR58bM HngAmwbscbfRd7cIrJpb94BTCVeQWWCf =gj5+ -----END PGP SIGNATURE-----
Mar 22 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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/
Mar 22 2009
parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Georg Wrede wrote:
 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/
Thanks, I've taken a look and it seems interesting except that it does a lot of things I don't really need... Jerome - -- mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknJNf4ACgkQd0kWM4JG3k9mcACgrP1/iDwPpSwFgQ2cxjaXoDiL likAn2FTdwDuH74VpIajG3NlpldUidXE =jkFw -----END PGP SIGNATURE-----
Mar 24 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Nick Sabalausky wrote:
 ""Jérôme M. Berger"" <jeberger 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".
Mar 22 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:gq5mp9$2htv$1 digitalmars.com...
 Nick Sabalausky wrote:
 ""Jérôme M. Berger"" <jeberger 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").
Mar 22 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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-Y9HQk&feature=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 :-(
Mar 22 2009
parent BCS <none anon.com> writes:
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.
Mar 22 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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>.
Mar 22 2009
parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----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:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknJODAACgkQd0kWM4JG3k9QPACeJtdkO9koz9bhYVm0DfiYZC0w 2cAAn3LGWDl2ytNm2MB5O9k08FfzI/Vz =oyLR -----END PGP SIGNATURE-----
Mar 24 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
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 *sloooooow* (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++, 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 loooove 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) ----------------------------------------------------------------------------
Mar 23 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
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) ----------------------------------------------------------------------------
Mar 23 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 23 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Mar 23, 2009 at 6:15 PM, Walter Bright
<newshound1 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.
Mar 23 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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!
Mar 23 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Mar 23, 2009 at 6:53 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 For what it's worth, most of the D wiki is incredibly out-of-date too.
 =A0I 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!
Mar 23 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Mon, Mar 23, 2009 at 6:53 PM, Walter Bright
 <newshound1 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.
Mar 23 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20090323192000.GA23612 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.
Mar 24 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
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. :-) )
Mar 23 2009
prev sibling parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
 </>
 
 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".
In a way you're right, but: - I had been looking for a way around the limitations of make for a while before I found SCons. In particular: - No easy way to make cross-platform Makefiles; - No easy way to track dependencies automatically; - No easy way to point at a folder and say "take everything in this folder, compile it, and link it into an executable named foo"; - File date is a poor way to decide that a file must be rebuilt, if you go back to an archived older version of the file make will miss it; - No way to use multi-core / multi-CPUs systems (the -j option is broken). Now that I found SCons, I look at the others mostly to satisfy my curiosity. I'm certainly not trying to "keep with the best". But then, I believe everyone here is curious about new things and software or we wouldn't be looking at D would we? ;) Jerome - -- mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknJOAEACgkQd0kWM4JG3k/gXQCff3oajwj0riRyzh7XQsy/QDqK UJIAn24ud9n47wGAuRhzHCQnEvzCY+DZ =zBjm -----END PGP SIGNATURE-----
Mar 24 2009
prev sibling next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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
Mar 21 2009
parent TomD <t_demmer nospam.web.de> writes:
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
Mar 21 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 21 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:gq2dv9$2vn3$1 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.
Mar 21 2009