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? 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 "mis"configuration.

 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

Reply via email to