{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifpjicuzadyfsznzgymqtdizows2yvhrf4wrctdlesbudcdr6xo5m",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3miw4jnv74uz2"
  },
  "path": "/viewtopic.php?t=33306&p=271990#p271990",
  "publishedAt": "2026-04-07T13:51:31.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> breaking the building process due to a redundant option seems... illogical. The logical way would be to add all such redundant/obsolete options to an internal list, and when any of them is encountered just notify the user about its status\n\nConfigure does exactly that.\n\n> 0:10.16 mozbuild.configure.options.InvalidOptionError: Unknown option: --enable-jxl\n\nit halts the build process at the first stage (very early in the build process) with the message that it's an invalid option.\nThis has been the way the Mozilla build system works for a long time. Invalid configure options are fatal.\n\n\n> I wonder, would that option's counterpart ( --disable-jxl ) be available and valid?\n\nit's not. And by treating invalid options as fatal, you aren't left guessing if your mozconfig options are actually doing anything or not. If you just let the build continue (most people won't view the compile output) then you get confusion \"why is my config option not working...?\"\n\nYou might think it's a \"bit harsh\" to do it that way but there is no real option to do it another way other than adding a bunch of complexity to the build system to have \"depreciation\" stages. And that's just overkill for a single application.\n\n* * *",
  "title": "Browser Development • Re: 34.2.0 build failed, --enable-jxl unknown ??",
  "updatedAt": "2026-04-07T13:51:31.000Z"
}