Hi Rob,
So we have 60-odd broken files all over CVS to support that; and all I
want to do is replace those 60-odd broken files with 4 working files in
the win32 directory that will generate 60-odd broken files on request if
you really really want them. My only question is, 'how much broken is
OK?'
Personally the change you made would be fine with me as I don't make
builds off of them and strictly use them for debugging/profiling. I did
test it out and it did produce the project files. Stas had mentioned that
he wanted to get them building (so in order to keep them around I would
help with getting them up to speed). So the question does really come down
to whether or not non-buildable dsp files are acceptable to everyone.
I think it would actually be counter-productive to have them buildable, to
be honest, but I'm willing to spend another day on it if what's there isn't
good enough for the uses those files are put to. I wasn't sure whether
project dependencies and include paths would be important in this regard,
for example. If they're not, we're good to go with last night's efforts :)
CC'ing him so he can chime in on this.
Really though, with time getting short, we should be spending more time on
the testing/fixing up of the 5.3 build and new libs than cosmetics.
There wasn't a lot wrong with the 5.3 build until very recently. I'm getting
all sorts of peculiar things now (GD failing to find libiconv, SimpleXML
failing to find SPL, etc etc). But you've seen the response if I touch
anything in that department.
The next thing on my personal TODO, apart from Phar-porting, is cleaning up
the compiler warnings across the core. Also we never came to a real
conclusion about versioning in core modules, but I guess that goes as
'cosmetic'.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
