Darin Fisher Assignee
	Description • 19 years ago

Disable updater if iconv not found

This only applies to Windows.

	Benjamin Smedberg
	Comment 2 • 19 years ago

I don't think this is a good idea. I think we should AC_MSG_ERROR and halt
configure, rather than making the build options depend on the particular machine.

	Darin Fisher Assignee
	Comment 3 • 19 years ago

OK, I was just following the example of --enable-extensions.  We AC_MSG_WARN
(and keep going) when we cannot build xmlterm, gnomevfs, venkman,
tridentprofile, and xforms due to missing prereqs.  Should those be changed too?
 Or, are those different somehow?

	Benjamin Smedberg
	Comment 4 • 19 years ago

Some are different, and some are wrong: tridentprofile, for example, could never
work on non-windows, so it makes sense to warn+disable, as it makes sense to
warn+disable gnomevfs on windows. But we should error out if gnomevfs doesn't
have the proper prerequistes on unix, we should error.

In any case, I don't want to end up in the situation where a misconfigured
tinderbox machine or build machine could succeed "accidentally" without building
the update system.

	Darin Fisher Assignee
	Comment 5 • 19 years ago

OK, that makes sense.

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 6 • 19 years ago

note that some of those build options warn+continue if enabled implicitly, but
halt if enabled explicitly (gnomevfs, for example).

Why should we show an error if gnomevfs dependencies are not found? That's not
how most other configure scripts are working.

	Benjamin Smedberg
	Comment 7 • 19 years ago

We are different from most configure-based products, in that we do not expect
people to configure themself and build from source, with whatever configuration
they happen to have: our build system is geared to producing end-user binaries,
and the host system that is doing the build should not in general affect build
options.

	cls
	Comment 8 • 19 years ago

Comment on attachment 186361 [details] [diff] [review]
v1 patch

I don't think win32 is the only platform that will not have iconv installed by
default.

Regarding hard & soft dependencies,  I believe that the only reason we starting
using the warn+disable method for certain items is because we didn't want to
have to keep track of a separate EXTENSIONS_ALL list for each platform. 
Otherwise, we have hard dependencies for practically everything else.  

Unless it's practically impossible to build a feature for a particular platform
(e.g., xmlterm for win32), we shouldn't let the installed packages on the
machine determine the feature set of the application.  

FWIW, if there was a AC_MSG_INFO, I would use that instead of warning about the
missing gnomevfs dependency when building on win32 since it's just an
informational message to inform people that not everything in the default or
all extension list is being built.  We could silently disable those but I think
that would lead to an equal or greater number of complaints.

	Darin Fisher Assignee
	Comment 9 • 19 years ago

> I don't think win32 is the only platform that will not have iconv installed by
> default.

The updater only needs iconv under win32, so I only require iconv under win32. 
Is this somehow not the right thing to do?

	Darin Fisher Assignee
	Comment 10 • 19 years ago

Changed AC_MSG_WARN to AC_MSG_ERROR.

	cls
	Comment 11 • 19 years ago

Comment on attachment 186419 [details] [diff] [review]
v1.1 patch

Sorry, I thought iconv was being called universally.

	Darin Fisher Assignee
	Comment 12 • 19 years ago

fixed-on-trunk