61907 - Use AC_ARG_WITH and AC_ARG_ENABLE right

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[olaf]

The configure.in script shows some instances of AC_ARG_WITH where AC_ARG_ENABLE
should have been used.
These macros work identically (apart from setting differently-named variables),
but it is convention that WITH is used only for _external_ packages, e.g.
AC_ARG_WITH(libpng, [--with-libpng[=DIR]  Use system libpng], ...)
and ENABLE is used to enable/disable internal features, e.g.
AC_ARG_ENABLE(extensions, [--enable-extensions  Compile in extensions], ...)

Also, there is an unwritten convention that the help texts be written like this:
--with-libpng[=DIR]  Use system libpng
i.e. write (literally) DIR instead of $dir and instead of NAME or anything else.
This helps e.g. for zsh with autocompletion.

Comment 1

[Keyser Sose]

Marking NEW so someone with more experience can look at it and
invalidate/validate it. 

Comment 2

[cls]

Setting milestones to Future.

Comment 3

[hacker formerly known as [e-mail]]

Attachment: Long overdue renaming

Comment 4

[hacker formerly known as [e-mail]]

As well as renaming certain options, I took this opportunity to reorganize
configure.in.  Options have been lumped into categories which makes the
webconfig output (with headers) make more sense.  Options & tests that have been
commented out for quite a while have been removed as well as tests for features
that we no longer support.

The following options have been removed:
--enable-monolithic-toolkit
--disable-jar-packaging

The following options have been renamed:

--with-jpeg                --with-system-jpeg
--with-zlib                --with-system-zlib
--with-png                 --with-system-png
--with-mng                 --with-system-mng
--enable-toolkit           --enable-default-toolkit
--with-gtk                 --enable-toolkit-gtk
--with-xlib                --enable-toolkit-xlib
--with-qt                  --enable-toolkit-qt
--enable-gle               --enable-gle-support
--with-extensions          --enable-extensions
--enable-modules           --enable-standalone-modules
--enable-lea               --enable-xpcom-lea
--enable-ultrasparc        --enable-js-ultrasparc
--enable-strip-libs        --enable-strip
--with-debug-modules       --enable-debug-modules
--with-dbgrinfo-modules    --enable-dbgrinfo-modules
--with-profile-modules     --enable-profile-modules
--enable-eazel-profiler    --enable-eazel-profiler-support
--enable-chrome            --enable-chrome-format
--enable-homedir           --with-user-appdir
--enable-static-components --enable-meta-component-modules

The old names will continue to work until the extra checks are removed next
milestone.

Comment 5

[hacker formerly known as [e-mail]]

Comment on attachment 54793 [details] [diff] [review]
Long overdue renaming

Argh. stupid dos-line endings.

Comment 6

[hacker formerly known as [e-mail]]

Attachment: Again, with the proper line-endings

Comment 7

[hacker formerly known as [e-mail]]

Attachment: Updated with newsgroup suggestions & fixed some MOZ_ARG usage

Comment 8

[timeless]

um. chrome hackers very much expect to be able to use --disable-jar-packaging.
not to mention the few people who build on systems where the jar packager isn't
installed. please put it back.

Comment 9

[hacker formerly known as [e-mail]]

As I've posted in the newsgroups a couple of times now, --disable-jar-packaging
has been deprecated for a couple of milestones now.  It's not coming back.  Use
--enable-chrome-format and start reading m.builds or at least look at the other
configure options first.  The jar packager? You mean zip?  It's a hard
requirement now as well.

Comment 10

[hacker formerly known as [e-mail]]

Most of the fallout seems to be over.  Marking fixed.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think this caused bug 108044.