phar in win32 snapshots

17 years ago by Greg Beaver — view source — reply

unread

Hi,

Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?

Greg

17 years ago by Pierre Joye — view source — reply

unread

hi,

Hi,

Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?

The default config.w32 (besides being wrong) is shared.

Why should it be built statically?

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Steph Fox — view source — reply

unread

Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?

The default config.w32 (besides being wrong) is shared.

ARG_ENABLE("phar", "disable phar support", "yes");

I'm still not in a position to test and uncover what you might mean by
'wrong' - just no time these days to spend however long it takes to install
a new compiler while backing up the old and etc etc etc. I do know, though,
that it all worked fine before the build system was 'upgraded' and several
of the other config.w32 files across the core were 'fixed' to accommodate
those changes.

Why should it be built statically?

Because that's what it says in the config file. Unless you've altered
ARG_ENABLE() to mean something different?

Steph

17 years ago by Pierre Joye — view source — reply

unread

Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?

The default config.w32 (besides being wrong) is shared.

ARG_ENABLE("phar", "disable phar support", "yes");

I'm still not in a position to test

I do know, though,
that it all worked fine before the build system was 'upgraded' and several
of the other config.w32 files across the core were 'fixed' to accommodate
those changes.

Let forget this attempt to yet again discredit the fantastic work
being done by the windows team and let us try to figure out what's
wrong.

The behavior has changed after your dependency patch, the 3rd argument
of EXTENSION has to be set to false if the extension has to be built
statically.

Why should it be built statically?

Because that's what it says in the config file.

What's the actual reason to build phar statically?

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Steph Fox — view source — reply

unread

Pierre,

I do know, though,
that it all worked fine before the build system was 'upgraded' and
several
of the other config.w32 files across the core were 'fixed' to accommodate
those changes.

Let forget this attempt to yet again discredit the fantastic work
being done by the windows team and let us try to figure out what's
wrong.

The behavior has changed after your dependency patch, the 3rd argument
of EXTENSION has to be set to false if the extension has to be built
statically.

The Windows team do not have control over all the config.w32 files out in
the wild. We don't even have control over all the config.w32 files in PECL.
You've now changed the meaning of two functions in the build system to my
knowledge, one of which I saw go in and tried hard to get reverted and the
other of which I didn't even know about until this moment. My complaints
were dismissed out of hand the first time around, and I guess I might as
well forget about even trying to complain now, right?

I can't believe I'm the only person who sees a problem with this top-down
approach to change. Doesn't anyone else even care?

Steph

17 years ago by Greg Beaver — view source — reply

unread

Pierre Joye wrote:

hi,

Hi,

Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?

The default config.w32 (besides being wrong) is shared.

Why should it be built statically?

It builds statically in vs 2008 with PHP_5_3 on my box, you are
mistaken. For reasoning on static build, see the list archive.

Thanks,
Greg

17 years ago by Pierre Joye — view source — reply

unread

hi,

Pierre Joye wrote:

hi,

Hi,

Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?

The default config.w32 (besides being wrong) is shared.

Why should it be built statically?

It builds statically in vs 2008 with PHP_5_3 on my box, you are
mistaken. For reasoning on static build, see the list archive.

Can you try to actually what is used to build a release please?

cscript /nologo configure.js --enable-snapshot-build --enable-debug-pack

And I still have no answer to my question. Why should it be built statically?

The change has been introduced with the extension dependencies patch
(or in the same period, to be checked, post alpha2 anyway).

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Steph Fox — view source — reply

unread

Can you try to actually what is used to build a release please?

cscript /nologo configure.js --enable-snapshot-build --enable-debug-pack

So the snapshot build no longer works with the same criteria as the rest of
the build system? Great.

And I still have no answer to my question. Why should it be built
statically?

Because thankfully, Pierre, you are not RM!

Steph

17 years ago by Pierre Joye — view source — reply

unread

hi,

Can you try to actually what is used to build a release please?

cscript /nologo configure.js --enable-snapshot-build --enable-debug-pack

So the snapshot build no longer works with the same criteria as the rest of
the build system? Great.

I wonder if I'm completely stupid or unable to get you actually read
the mails before complaining endlessly and obviously 48hours before
the release because we have nothing else to do than that.

And I still have no answer to my question. Why should it be built
statically?

Because thankfully, Pierre, you are not RM!

Take a big breath, smoke something, and then try to reply again after
having carefully read my replies. Thanks.

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Steph Fox — view source — reply

unread

I wonder if I'm completely stupid or unable to get you actually read
the mails before complaining endlessly and obviously 48hours before
the release because we have nothing else to do than that.

I complain endlessly because I see an apparently endless line of things that
worry me, some of which - like this one - are hidden from view.

And I still have no answer to my question. Why should it be built
statically?

Because thankfully, Pierre, you are not RM!

Take a big breath, smoke something, and then try to reply again after
having carefully read my replies. Thanks.

I have a better idea. Next time you make a change that impacts the way
extensions are built and distributed, recognize that you have a
responsibility to fix any ensuing breakage. It would save a lot of confusion
and unpleasantness.

Whether an extension is enabled by default (ie built-in statically) or not
is the decision of the Release Management team. Not you. Not me. Not Greg.
Not Tony. I'm not sure what's so hard to understand about that.

Steph

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Kalle Sommer Nielsen — view source — reply

unread

2008/8/30 Steph Fox steph@php.net

Can you try to actually what is used to build a release please?

cscript /nologo configure.js --enable-snapshot-build --enable-debug-pack

So the snapshot build no longer works with the same criteria as the rest of
the build system? Great.

And I still have no answer to my question. Why should it be built

statically?

Because thankfully, Pierre, you are not RM!

I failed to see what Pierre not being RM has to do with not replying with
why Phar shouldn't
be built staticlly (Im not against it or anything). I think I can count 3
times, each in every mail
from Pierre asking why and you seems to ignore them. Just reading this
thread didn't get us
any further and it seems like an endless loop, where Pierre is asking for
the reason, and it
doesn't get anywhere.

Im sorry for bragging into the thread like this, but I just wanted to give
my input on this :)

Steph

--

Thanks

Kalle Sommer Nielsen

17 years ago by Greg Beaver — view source — reply

unread

Pierre Joye wrote:

hi,

Pierre Joye wrote:

hi,

Hi,

Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?

The default config.w32 (besides being wrong) is shared.

Why should it be built statically?

It builds statically in vs 2008 with PHP_5_3 on my box, you are
mistaken. For reasoning on static build, see the list archive.

Can you try to actually what is used to build a release please?

cscript /nologo configure.js --enable-snapshot-build --enable-debug-pack

And I still have no answer to my question. Why should it be built statically?

The change has been introduced with the extension dependencies patch
(or in the same period, to be checked, post alpha2 anyway).

Hi,

Right, my point is that this:

configure --enable-debug-pack

builds phar in statically, just as zlib is built statically. Perhaps
the --enable-snapshot-build could be fixed to match this behavior? It
makes it hard to design config.w32 for multiple branches if it behaves
differently with different unrelated config options.

Thanks,
Greg

P.S. I'm not trying to start a war over anybody's code religion, just
asking for an obvious bug in the build process to be corrected.

17 years ago by Pierre Joye — view source — reply

unread

Right, my point is that this:

configure --enable-debug-pack

builds phar in statically, just as zlib is built statically. Perhaps
the --enable-snapshot-build could be fixed to match this behavior?

That's my point yes. The change has been introduced with the extension
dependency patch from Steph. I don't have the time to dig in now and
I'm not willing to change this part before alpha2 but there is an easy
fix (see below).

It
makes it hard to design config.w32 for multiple branches if it behaves
differently with different unrelated config options.

You can simply change the EXTENSION call to:

EXTENSION("phar", "dirstream.c func_interceptors.c phar.c
phar_object.c phar_path_check.c stream.c tar.c util.c zip.c", false);

and the problem will be gone. The false set the "shared" argument to
false (problem is that PHP_XYZ_SHARED is set to NULL now or smtg
similar). I will have time after alpha2 to dig into this problem and
apply a fix.

Thanks,
Greg

P.S. I'm not trying to start a war over anybody's code religion, just
asking for an obvious bug in the build process to be corrected.

Yes, I should have not replied to other mails in this thread as they
are completely irrelevant to the actual problem (or solution).
noise--;

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Greg Beaver — view source — reply

unread

Pierre Joye wrote:

Right, my point is that this:

configure --enable-debug-pack

builds phar in statically, just as zlib is built statically. Perhaps
the --enable-snapshot-build could be fixed to match this behavior?

That's my point yes. The change has been introduced with the extension
dependency patch from Steph. I don't have the time to dig in now and
I'm not willing to change this part before alpha2 but there is an easy
fix (see below).

It
makes it hard to design config.w32 for multiple branches if it behaves
differently with different unrelated config options.

You can simply change the EXTENSION call to:

EXTENSION("phar", "dirstream.c func_interceptors.c phar.c
phar_object.c phar_path_check.c stream.c tar.c util.c zip.c", false);

and the problem will be gone. The false set the "shared" argument to
false (problem is that PHP_XYZ_SHARED is set to NULL now or smtg
similar). I will have time after alpha2 to dig into this problem and
apply a fix.

OK, Johannes/Lukas, any objection to me changing the phar config.w32 for
alpha2, and reverting when the core issue in the build is fixed? This
is a pretty minor issue that only affects people making release builds.

Greg

17 years ago by Pierre Joye — view source — reply

unread

and the problem will be gone. The false set the "shared" argument to
false (problem is that PHP_XYZ_SHARED is set to NULL now or smtg
similar). I will have time after alpha2 to dig into this problem and
apply a fix.

OK, Johannes/Lukas, any objection to me changing the phar config.w32 for
alpha2, and reverting when the core issue in the build is fixed? This
is a pretty minor issue that only affects people making release builds.

Without playing the RM ;-) please go ahead, the delay between the
commit freeze and the release was requested by me for this exact
reason: fix build issue before the release :)

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Hannes Magnusson — view source — reply

unread

Hi,

Is there a reason phar is built shared in win32 snapshots even though
the default in config.w32 is to build it statically?

Isn't there a internals-win@ list ? :)

-Hannes