PHP 4 win build system questions

19 years ago by techtonik — view source

unread

||()|| Greetings, phpinnards.. =)

I tried to automate build system for PHP 4 a bit and after that
can't get some stupid questions out of my head. Install instructions
located as usual http://www.php.net/manual/en/install.windows.building.php

There are at least two inconveniences:

Need to copy bison.sample from win32build\bin to c:\usr\local\lib
Need to recompile resolv.lib every time target changes

So the questions are the following
1.1 Why not to get rid of this bison.sample copy operation either by
1.1.1 upgrade bison.exe in win32build.zip from 1.27 to at
least 1.34, which adds -S options to specify bison.sample
explicitly and also includes some memory leak fixes
http://sourceforge.net/project/shownotes.php?release_id=274058
or
1.1.2 set up environment variable BISON_SIMPLE somewhere in
build files/scripts?

2.1 Why resolv.lib needs to be recompiled every time when target
changes from "debug" to "release" and vice versa
2.1.1 Why it is not possible to supply a separate resolv_debug.lib
and resolv_release.lib files in win32build.zip and rewrite
dependencies for them in windows build files?

Thanks.

.techtonik

19 years ago by Wez Furlong — view source

unread

If you have cygwin flex and bison, you don't need to copy anything.
You also don't have to recompile resolv.lib; just build a release
build and use that, even when you're building a debug version of PHP.

--Wez.

||()|| Greetings, phpinnards.. =)

I tried to automate build system for PHP 4 a bit and after that
can't get some stupid questions out of my head. Install instructions
located as usual http://www.php.net/manual/en/install.windows.building.php

There are at least two inconveniences:

Need to copy bison.sample from win32build\bin to c:\usr\local\lib

Need to recompile resolv.lib every time target changes

So the questions are the following
1.1 Why not to get rid of this bison.sample copy operation either by
1.1.1 upgrade bison.exe in win32build.zip from 1.27 to at
least 1.34, which adds -S options to specify bison.sample
explicitly and also includes some memory leak fixes
http://sourceforge.net/project/shownotes.php?release_id=274058
or
1.1.2 set up environment variable BISON_SIMPLE somewhere in
build files/scripts?

2.1 Why resolv.lib needs to be recompiled every time when target
changes from "debug" to "release" and vice versa
2.1.1 Why it is not possible to supply a separate resolv_debug.lib
and resolv_release.lib files in win32build.zip and rewrite
dependencies for them in windows build files?

Thanks.

.techtonik

19 years ago by techtonik — view source

unread

If you have cygwin flex and bison, you don't need to copy anything.

And if I don't have any? Can it be made as simple as "unpack and compile"?
If you'll read this page
http://www.php.net/manual/en/install.windows.building.php
you notice redundant instructions for copying files and setting up
MSVC++. I've made a .bat file to automate the process and avoid making
these repeated operations manually every time I need to compile PHP 4
for testing. I'm looking into get this process even more simple and
without unnecessary garbage left on my c: drive. Files are attached.

You also don't have to recompile resolv.lib; just build a release
build and use that, even when you're building a debug version of PHP.

Why do I need to build it at all if it is included in win32build.zip?

Should I update installation instructions on
http://www.php.net/manual/en/install.windows.building.php then?

--Wez.

||()|| Greetings, phpinnards.. =)

I tried to automate build system for PHP 4 a bit and after that
can't get some stupid questions out of my head. Install instructions
located as usual
http://www.php.net/manual/en/install.windows.building.php

There are at least two inconveniences:

Need to copy bison.sample from win32build\bin to c:\usr\local\lib

Need to recompile resolv.lib every time target changes

So the questions are the following
1.1 Why not to get rid of this bison.sample copy operation either by
1.1.1 upgrade bison.exe in win32build.zip from 1.27 to at
least 1.34, which adds -S options to specify bison.sample
explicitly and also includes some memory leak fixes

http://sourceforge.net/project/shownotes.php?release_id=274058
    or
  1.1.2 set up environment variable BISON_SIMPLE somewhere in
        build files/scripts?
2.1 Why resolv.lib needs to be recompiled every time when target
changes from "debug" to "release" and vice versa
2.1.1 Why it is not possible to supply a separate resolv_debug.lib
and resolv_release.lib files in win32build.zip and rewrite
dependencies for them in windows build files?

Thanks.

.techtonik

19 years ago by Wez Furlong — view source

unread

I don't want to burst your bubble, but PHP 5 is the current release of
PHP, and we've started work on PHP 6. The win32 build system is much
more friendly; I've already spent many hours on making things better
there.

If you want to improve things for PHP 4, go for it, but I don't and
won't have time to help review it; my "php time" is focused on the
current stuff.

Don't forget that we have full-on win32 builds being generated
courtesy of Edin, along with several snapshot builds throughout the
day for all branches of PHP and PECL; there should be very little need
for people to build their own, unless they are hacking on PHP
itself--those people should be maintaining their own build
environments.

--Wez.

If you have cygwin flex and bison, you don't need to copy anything.

And if I don't have any? Can it be made as simple as "unpack and compile"?
If you'll read this page
http://www.php.net/manual/en/install.windows.building.php
you notice redundant instructions for copying files and setting up
MSVC++. I've made a .bat file to automate the process and avoid making
these repeated operations manually every time I need to compile PHP 4
for testing. I'm looking into get this process even more simple and
without unnecessary garbage left on my c: drive. Files are attached.

You also don't have to recompile resolv.lib; just build a release
build and use that, even when you're building a debug version of PHP.

Why do I need to build it at all if it is included in win32build.zip?

Should I update installation instructions on
http://www.php.net/manual/en/install.windows.building.php then?
--Wez.

||()|| Greetings, phpinnards.. =)

I tried to automate build system for PHP 4 a bit and after that
can't get some stupid questions out of my head. Install instructions
located as usual
http://www.php.net/manual/en/install.windows.building.php

There are at least two inconveniences:

Need to copy bison.sample from win32build\bin to c:\usr\local\lib

Need to recompile resolv.lib every time target changes

So the questions are the following
1.1 Why not to get rid of this bison.sample copy operation either by
1.1.1 upgrade bison.exe in win32build.zip from 1.27 to at
least 1.34, which adds -S options to specify bison.sample
explicitly and also includes some memory leak fixes

http://sourceforge.net/project/shownotes.php?release_id=274058
    or
  1.1.2 set up environment variable BISON_SIMPLE somewhere in
        build files/scripts?
2.1 Why resolv.lib needs to be recompiled every time when target
changes from "debug" to "release" and vice versa
2.1.1 Why it is not possible to supply a separate resolv_debug.lib
and resolv_release.lib files in win32build.zip and rewrite
dependencies for them in windows build files?

Thanks.

.techtonik

19 years ago by techtonik — view source

unread

I don't want to burst your bubble, but PHP 5 is the current release of
PHP, and we've started work on PHP 6.

Do as you wish, but I though PHP4 is still the most widely supported version
on the web and if you're going to conquer the world you have to think about
those users, who was already conquered. =) I mean it is not uncommon
situation when you've asked for a PHP 4 version of extension or problem with
PHP and you have to compile it from scratch since PHP.NET
http://PHP.NETdoesn't provide debug version.

It is good you've started PHP 6. Sorry what I didn't participated in
discussion - it seems that it is prerogative of core PHP developers and not
it's users. Even if I'd like to follow the process - it is too blurred
through ML to find a time and filter essentials to analyze. I like ML for
it's archives and chit-chat, but my decision-making framework seems to have
problems with such kind of requirements gathering system. Sorry, feel free
to flight into bright future without me - I'll better to track it from the
ground moving slowly and watching reaction of the web. =)

The win32 build system is much

more friendly; I've already spent many hours on making things better
there.

If you want to improve things for PHP 4, go for it, but I don't and
won't have time to help review it; my "php time" is focused on the
current stuff.

Is there any developers who officially supports PHP 4 branch?

Don't forget that we have full-on win32 builds being generated

courtesy of Edin, along with several snapshot builds throughout the
day for all branches of PHP and PECL; there should be very little need
for people to build their own, unless they are hacking on PHP
itself--those people should be maintaining their own build
environments.

I think I've got the idea. Should. Bye.

--t.

19 years ago by Wez Furlong — view source

unread

Is there any developers who officially supports PHP 4 branch?

Yes, we "support" people using it, but not so much people building it.
We're trying to shift people on to PHP 5 so that the support burden
is lessened. If you're building it yourself, you're competent enough
to support yourself building it.

Don't forget that we have full-on win32 builds being generated
courtesy of Edin, along with several snapshot builds throughout the
day for all branches of PHP and PECL; there should be very little need
for people to build their own, unless they are hacking on PHP
itself--those people should be maintaining their own build
environments.

I think I've got the idea. Should. Bye.

All I'm trying to say is that we have the things the way they are
because its easier and less time consuming for most people using and
developing PHP; don't let me discourage you.

--Wez.

19 years ago by techtonik — view source

unread

||()|| [..konnichi wa, ogenki desu ka, Wez../]

Is there any developers who officially supports PHP 4 branch?

WF> Yes, we "support" people using it, but not so much people building it.
WF> We're trying to shift people on to PHP 5 so that the support burden
WF> is lessened. If you're building it yourself, you're competent enough
WF> to support yourself building it.

I might be compenent, but it was a waste of time. I'm not an OOP
programmer and I don't like PHP 5 yet. Thought I'm not alone. I
better not to deal with PHP 5 if you're going to support it like
that when PHP 6 is out.

Just wanted to help. I forgot about C long ago and do not have too
much experience to answer stupid questions myself. Sorry to bother
you.

Maybe you need to expand developers base somehow or make advanced
hot patch submission/review/approval/integration system on top of
chora, so less time will be wasted to review patch submissions.

Don't forget that we have full-on win32 builds being generated
courtesy of Edin, along with several snapshot builds throughout the
day for all branches of PHP and PECL; there should be very little need
for people to build their own, unless they are hacking on PHP
itself--those people should be maintaining their own build
environments.

I think I've got the idea. Should. Bye.

WF> All I'm trying to say is that we have the things the way they are
WF> because its easier and less time consuming for most people using and
WF> developing PHP; don't let me discourage you.

Do as you wish.

WBR.techtonik

(B)uilding, (A)ntenna, (S)pan and (E)arth

terminal velocity - 54m/s, 305m *

19 years ago by Antony Dovgal — view source

unread

I might be compenent, but it was a waste of time. I'm not an OOP
programmer and I don't like PHP 5 yet.

I could never understand people saying that PHP5 is about OOP.
It's like saying that kernel 2.6 is about desktop.

True, PHP5 has improved OO support, but that doesn't mean that it hurts procedural style in any way.
If you want more stable PHP version - update it regularly.
Staying with DOS 6.22 and saying that you don't like those new OSes may be fine, but it doesn't make much sense to me..

Maybe you need to expand developers base somehow or make advanced
hot patch submission/review/approval/integration system on top of
chora, so less time will be wasted to review patch submissions.

That still doesn't add much point to supporting 4 branches (4, 5.0, 5.1 & HEAD) in the same time.
Actually I would object even if you want to do it yourself.

--
Wbr,
Antony Dovgal

19 years ago by anatoly techtonik — view source

unread

||()|| [..konnichi wa, ogenki desu ka, Antony../]

I might be compenent, but it was a waste of time. I'm not an OOP
programmer and I don't like PHP 5 yet.
AD> I could never understand people saying that PHP5 is about OOP.
AD> It's like saying that kernel 2.6 is about desktop.

You will never understand them, because you're core developer, who
knows everything. If you want to know why PHP 5 is about OOP - try
to imagine hosting provider asking "What's new in PHP 5?". Quote
from manual:

"PHP 5 and the integrated Zend Engine 2 have greatly improved PHP's
performance and capabilities, but great care has been taken to break
as little existing code as possible. "

so the answers are

New Zend Engine 2
Backward compatibility break

Take a look at ZendEngine-2.0.pdf. ToC

Overview ................................................. 5
Revamped object model using object handles ............... 6
New Object Model Related Changes......................... 11
Additional Features...................................... 25
Multiple Inheritance .................................. 25
Private Member Variables .............................. 27
Static Class Member Variables ......................... 29
Exception handling (try/throw/catch) .................. 31
Revamped OO Syntax Overloading......................... 34
String offset syntax................................... 36

And you say what this is not about OOP? When what about?

For hosting providers it is important, because OOP applications are
bigger and make more server load together with all features. But not
as important as second compatibility break. Despite of

"migrating your code from PHP
4 to 5 should be very easy. Most existing PHP 4 code should be ready
to run without changes, but you should still know about the few
differences and take care to test your code before switching versions
in production environments."

that means nothing more than a big pack of troubles for hosters. No
matter how minor is this break - it is not their job to mess with PHP
code of their customers on next major server upgrade and customers do
not want any more troubles with code, which already works. This is the
main factor that stops PHP 5 progress and not my desire to stick with
PHP 4 forever.

I do not know why am I arguing. It is useless anyways. =)

AD> True, PHP5 has improved OO support, but that doesn't mean
AD> that it hurts procedural style in any way.

I already explained how it hurts. No matter how minor is BC break if
it can cause working system failure.

AD> If you want more stable PHP version - update it regularly.
AD> Staying with DOS 6.22 and saying that you don't like those
AD> new OSes may be fine, but it doesn't make much sense to me..

Bad abstraction. DOS 6.22 is not deployed and used as widely as
PHP 4 at the moment.

Maybe you need to expand developers base somehow or make advanced
hot patch submission/review/approval/integration system on top of
chora, so less time will be wasted to review patch submissions.

AD> That still doesn't add much point to supporting 4 branches
AD> (4, 5.0, 5.1 & HEAD) in the same time.

Abandon 5.0 if 5.1 is stable. Remove PHP 4 together with PHP 3 into
archive. Make it clear PHP 4 isn't supported any more and make us
believe PHP 5 is good, stable way to go. You may start with
sourceforge.

AD> Actually I would object even if you want to do it yourself.

I'm not pretending.

WBR.techtonik

(B)uilding, (A)ntenna, (S)pan and (E)arth

terminal velocity - 54m/s, 305m *