flags for base's configure script: should there be more or fewer? (was Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl)
Bringing this discussion to macports-dev as suggested. Anyways, r117621https://trac.macports.org/changeset/117621 removed a bunch of flags from the configure script in base, many of which I found useful. Personally, I generally prefer giving users more configure options rather than fewer, as I respect users' freedom to build their software the way that they want to, and would prefer that exercising that freedom remains as easy as possible (here, in the form of providing configure flags, but the concept can also be extended to things like adding more variants to Portfiles). Anyways, that is my personal preference at least, which way are other people on this list leaning? larryv at least has already come out as deletionist, but what about the rest of you? -- Forwarded message -- From: MacPorts nore...@macports.org Date: Fri, Mar 7, 2014 at 2:50 PM Subject: Re: [MacPorts] #42756: macports doesn't compile with bundled tcl To: xeron.os...@gmail.com, macports-tick...@lists.macosforge.org Cc: rai...@macports.org, eg...@gwmail.gwu.edu #42756: macports doesn't compile with bundled tcl + Reporter: xeron.oskom@... | Owner: macports-tickets@... Type: defect | Status: new Priority: Normal | Milestone: Component: base |Version: 2.2.99 Resolution: | Keywords: Port: | + Comment (by larryv@...): Replying to [comment:8 egall@...]: Replying to [comment:6 cal@...]: That increases the possibility for misconfigurations (such as choosing Tcl 8.6), If a user is building from source themselves, they should be aware of that. Also I fail to see why choosing Tcl 8.6 is considered a misconfiguration. It's a misconfiguration because we don't support it. I just checked out trunk and the sqlite3 one still exists, too. Also while the `--with-included-tclthread` flag may be gone now, I would argue that should be brought back as well This isn't the place for this conversation (take it to macports-dev if you wish), but I strongly oppose adding more configuration flags than the ones we already have. I wouldn't be opposed to removing even more of them. -- Ticket URL: https://trac.macports.org/ticket/42756#comment:10 MacPorts http://www.macports.org/ Ports system for OS X ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: flags for base's configure script: should there be more or fewer? (was Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl)
On 2014-3-8 07:13 , Eric Gallager wrote: Bringing this discussion to macports-dev as suggested. Anyways, r117621 https://trac.macports.org/changeset/117621 removed a bunch of flags from the configure script in base, many of which I found useful. Personally, I generally prefer giving users more configure options rather than fewer, as I respect users' freedom to build their software the way that they want to, and would prefer that exercising that freedom remains as easy as possible (here, in the form of providing configure flags, but the concept can also be extended to things like adding more variants to Portfiles). Anyways, that is my personal preference at least, which way are other people on this list leaning? Batteries included is generally preferable to more variants. I would tend to agree that the problem in the ticket is user error, but OTOH it's easy to have CFLAGS lying around in your environment and forget to unset them. Maybe we should at least delete flags containing $PREFIX from CFLAGS and LDFLAGS like we do PATH. Looks like the flags removed by r117621 were: --with-tcl --with-tclinclude --with-tclpackage --with-tcl-sqlite3= --with-included-tclthread As Tcl is now part of base, my view would be that providing flags to use a different one would make about as much sense as providing --with-pextlib= or --with-cregistry=. larryv at least has already come out as deletionist, but what about the rest of you? Name calling really doesn't help your case. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: flags for base's configure script: should there be more or fewer? (was Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl)
On Fri, Mar 7, 2014 at 4:09 PM, Joshua Root j...@macports.org wrote: On 2014-3-8 07:13 , Eric Gallager wrote: Bringing this discussion to macports-dev as suggested. Anyways, r117621 https://trac.macports.org/changeset/117621 removed a bunch of flags from the configure script in base, many of which I found useful. Personally, I generally prefer giving users more configure options rather than fewer, as I respect users' freedom to build their software the way that they want to, and would prefer that exercising that freedom remains as easy as possible (here, in the form of providing configure flags, but the concept can also be extended to things like adding more variants to Portfiles). Anyways, that is my personal preference at least, which way are other people on this list leaning? Batteries included is generally preferable to more variants. I would tend to agree that the problem in the ticket is user error, but OTOH it's easy to have CFLAGS lying around in your environment and forget to unset them. Maybe we should at least delete flags containing $PREFIX from CFLAGS and LDFLAGS like we do PATH. Looks like the flags removed by r117621 were: --with-tcl --with-tclinclude --with-tclpackage --with-tcl-sqlite3= --with-included-tclthread As Tcl is now part of base, my view would be that providing flags to use a different one would make about as much sense as providing --with-pextlib= or --with-cregistry=. Many other software packages include other software packages as part of their base, and the general trend is to only use the included one as a fallback in case one is not already installed. For example I was working with the sources of gnutls earlier today and they only fall back to using their included libtasn1 when the configure script fails to find one installed, and using the included one produces a warning. This is because libtasn1 is not actually something that gnutls maintains themselves, they only vendor it in as a convenience. Bringing it back to MacPorts, the copy of Tcl that is vendored in is more like libtasn1 in gnutls, in that MacPorts only vendors it in as a convenience and does not actually maintain it itself, which is why the tarball remains untarred until it is needed. Meanwhile the pextlib and cregistry libraries are not found anywhere else externally, because they are only used in MacPorts internally so far. It makes no sense to include flags for them because there is nowhere else that they could point, whereas on the other hand with Tcl, there are many other places that the flag for them could point. So I would argue that because of this, it actually makes *much* more sense to include a --with-tcl= flag than either a --with-pextlib= flag or a --with-cregistry= flag. larryv at least has already come out as deletionist, but what about the rest of you? Name calling really doesn't help your case. - Josh The label deletionist isn't name-calling, it's an accurate term for a philosophical position that people can have towards content in community-based software projects: https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia Many people apply the label to themselves voluntarily. Sorry for any offense caused by my using it, I just assumed that people were familiar with the term... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: flags for base's configure script: should there be more or fewer? (was Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl)
From the article: Being called an inclusionist or deletionist can sidetrack the issue from the actual debate,[21]” On Mar 7, 2014, at 17:06, Eric Gallager eg...@gwmail.gwu.edu wrote: https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: flags for base's configure script: should there be more or fewer? (was Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl)
On Mar 7, 2014, at 5:06 PM, Eric Gallager eg...@gwmail.gwu.edu wrote: libtasn1 is not actually something that gnutls maintains themselves, they only vendor it in as a convenience. Bringing it back to MacPorts, the copy of Tcl that is vendored in is more like libtasn1 in gnutls, in that MacPorts only vendors it in as a convenience This is a specious comparison. We are NOT packaging Tcl as a fallback; we're enforcing a specific configuration to ease MacPorts development. We don't particularly want to support users choosing their own preferred Tcl, and I don't see how doing so would benefit us (or them, frankly). As Josh intimated, batteries included is MacPorts' general philosophy. Our loose goal is to provide only as much choice as makes sense. The desire to provide freedom to end-users must be balanced with the fact that the complexity of the system grows exponentially with each additional option, making maintenance and support that much more difficult. If someone wants to customize their software in a way that we don't support, they're entirely free to build it by hand, or to maintain a local ports tree, or to do anything at all. larryv at least has already come out as deletionist, but what about the rest of you? Name calling really doesn't help your case. The label deletionist isn't name-calling, it's an accurate term for a philosophical position that people can have towards content in community-based software projects: https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia Many people apply the label to themselves voluntarily. Sorry for any offense caused by my using it, I just assumed that people were familiar with the term... Having spent much of the last 9 years contributing to the English Wikipedia — first as a regular user, then as an administrator — I am *quite* familiar with those terms. They have rather negative connotations. Labeling someone inclusionist or deletionist is rather like labeling someone a peacenik or a warmonger: You might be correct in a denotational sense, but you're also (strongly) implying that their position should be dismissed out of hand because it is illogical and driven by zealotry. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: flags for base's configure script: should there be more or fewer? (was Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl)
Hi, Many other software packages include other software packages as part of their base, and the general trend is to only use the included one as a fallback in case one is not already installed. For example I was working with the sources of gnutls earlier today and they only fall back to using their included libtasn1 when the configure script fails to find one installed, and using the included one produces a warning. This is because libtasn1 is not actually something that gnutls maintains themselves, they only vendor it in as a convenience. Bringing it back to MacPorts, the copy of Tcl that is vendored in is more like libtasn1 in gnutls, in that MacPorts only vendors it in as a convenience and does not actually maintain it itself, which is why the tarball remains untarred until it is needed. Meanwhile the pextlib and cregistry libraries are not found anywhere else externally, because they are only used in MacPorts internally so far. It makes no sense to include flags for them because there is nowhere else that they could point, whereas on the other hand with Tcl, there are many other places that the flag for them could point. So I would argue that because of this, it actually makes much more sense to include a --with-tcl= flag than either a --with-pextlib= flag or a --with-cregistry= flag. I wouldn't compare what libtasn1 is for gnutls with what Tcl is for MacPorts: - Tcl is a much more integral part of MacPorts than libtasn1 is for gnutls - The environments where GnuTLS is used often probably have either a usable version or none at all - Most package managers will make sure the version of libtasn1 matches GnuTLS' requirements - Most package managers control both the GnuTLS package and the libtasn1 package In MacPorts, we have a completely different setup: - Some of the platforms MacPorts runs on are getting harder and harder to support because of an outdated Tcl - We could specifically deploy a custom Tcl on only these platforms, but that would make it * extremely hard to test for most developers (including me) * introduce more possible configuration variables that have an effect on runtime complexity (such as the Tcl package path) * reduce the test coverage because of the explosion of possible variant combinations * add a whole new list of systems to test on once we move to Tcl 8.6 - MacPorts doesn't control the Tcl it uses; we don't even know whether 10.9+1 will ship Tcl 8.5, Tcl 8.6 or no Tcl at all. - MacPorts doesn't control the Tcl package setup; remember MacPorts base wouldn't configure on vanilla Mavericks because tclConfig.sh was moved to the command line tools package The very same arguments hold for Tcllib and the Tcl Thread package (e.g. Tiger lacks Tcllib completely AFAIK, preventing its use in MacPorts, and even if it is present, we can't possibly test for all Tcllib versions, and we can't fix any bugs they might have). The label deletionist isn't name-calling, it's an accurate term for a philosophical position that people can have towards content in community-based software projects: https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia I'm not sure an article called Deletionism and Inclusionism in Wikipedia applies to community-based software(!) projects. Remember Wikipedia is not a software project. Also, Wikipedia has its very own set of (partly home-grown) problems that don't necessarily apply to us (have you seen a portmgr@ member make a controversial decision on this list?). In fact, I don't think this article applies outside Wikipedia at all. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
