Re: [INTERNALS-WIN] [PATCH] Static dependency errors

hi,

On Sat, Jul 19, 2008 at 9:28 PM, Steph Fox <[email protected]> wrote:

> The attached patch ('ware DOS!) introduces a new configure switch, currently
> "--disable-build-errors" but I'm open to suggestions there.
>
> When build-errors is disabled, the two scenarios that can cause configure to
> stop mid-way (static lib with a hard dependency on a shared lib or static
> lib with a hard dependency on a missing static lib) will instead throw a
> "BUILD ERROR" (equivalent to the existing WARNING) and disable the offending
> static library.
>
> If the switch isn't invoked, configure just dies. It has been this way from
> inception for the first of those conditions, but only for the last 6 months
> for the (much more common) second. I was responsible for adding that second
> error, the rationale at the time being that the actual **build** used to
> fail without prior warning.

As part of online discussion and IRC, we already define this behavior.
It was also discussion to have different levels of configure errors
(warning, fatal, etc.). The idea is also to display only the relevant
information and it is what the summary begin to do (while leaving the
possibility to have a verbose and noisy output as now).

> In an off-list exchange with Rob, he wrote that he'd rather have faulty
> static extensions disabled by default and use a configure switch to force a
> full error. I'm the other way around on that, but if Rob's is the majority
> opinion it would be trivial to make it work that way.

You may consider to discuss things off list.  You would have been told
to wait a couple of days instead (Rob knows it but he may have forgot
to mention that in your discussions) as I already said that I'm
working on these changes.

> Why do I think this is important? Primarily because of the changes that have
> been made to local config.w32 files to work around the existing situation.
> Most of the internals developers (including/especially PECL devs) develop
> under *nix-based systems, so I think making it very, very simple to write a
> Windows configuration file is crucial for them - not to mention for any
> Windows-based 'newbs' who may happen along. The focus has always been on
> keeping PHP development simple; we should avoid any complications filtering
> down to extension authors where possible.

The changes I made (like for DOM) are part of this task and are
desired, they will remain like it is now. As a (small) proof of its
goodness, you can now build php without having any library available
but resolv.lib (and this one will be dropped soon as well).

About the difficulty to write config.32, I can't agree. It is very
easy to write a config.w32 file for Windows, even with our recent
changes (which are only about checking that a given requirement is
full filled).

The unix-like output is the worst thing ever, it is almost impossible
to quickly match the relevant warning or errors.  Many newbies even
prefer the new outputs instead of the unreadable unix-like one. They
ask for more improvements like that.

I'm sorry but I'm not in favor of applying this patch as it covers
something that is covered by the upcoming error level and logging
option. Please don't commit it.


Cheers,
---
Pierre

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