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