Response files

[Nick Sabalausky]

""Jérôme M. Berger"" <jeberger at free.fr> wrote in message 
news:gq4pop$154r$1 at 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.