<div dir="ltr"><div><div><div><div>Thanks for the feedback, Ryan.<br><br>> Is there a particular reason why it should be a variant, as opposed to 
just always building and installing the tools in the sqlite3 port?<br><br></div>That's the most convenient solution to be sure. I wasn't sure if, perhaps, sqlite3 is such a prolifically depended-upon port that to keep things lightweight it was using the amalgamation distro (building the tools requires building from the full distro, and brings in the tcl dependency).<br><br></div>If there's no reason not to build the tools by default then I will do that.<br><br></div>Thanks,<br></div>Aaron<br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 13, 2017 at 8:52 AM Ryan Schmidt <<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
On Jan 12, 2017, at 01:58, Aaron Madlon-Kay wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hi all. I was hoping to get some advice:<br class="gmail_msg">
><br class="gmail_msg">
> I want to make the sqlite3-tools package available via MacPorts (binaries available at <a href="https://sqlite.org/download.html" rel="noreferrer" class="gmail_msg" target="_blank">https://sqlite.org/download.html</a>); this package contains three binaries: sqlite3 CLI shell, sqldiff, and sqlite3_analyzer.<br class="gmail_msg">
><br class="gmail_msg">
> Problem:<br class="gmail_msg">
><br class="gmail_msg">
> sqlite3_analyzer requires TCL; it turns out the `tcl` port actually includes sqlite3_analyzer built from its own bundled copy of sqlite3, but it is an older version. This older version is installed to ${prefix}/bin, so it conflicts with any newer version we might try to install.<br class="gmail_msg">
><br class="gmail_msg">
> Questions:<br class="gmail_msg">
><br class="gmail_msg">
> - Is it common knowledge that sqlite3_analyzer is available as part of TCL? Its inclusion there seems coincidental, perhaps just due to the fact that it's implemented in TCL?<br class="gmail_msg">
>   - If no, can we remove it from the `tcl` port?<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
I was not aware it was in the tcl port. Sounds like a good idea to remove it from there.<br class="gmail_msg">
<br class="gmail_msg">
> - If sqlite3_analyzer can't be removed from the `tcl` port, should the newer binary have a different name or be put in a different path? Is there a standard scheme for disambiguation like this?<br class="gmail_msg">
><br class="gmail_msg">
> - If no to all above, sqlite3_analyzer can be built against the system-provided TCL framework, and the port can be marked as incompatible with the `tcl` port. Is that acceptable? (I would think not)<br class="gmail_msg">
><br class="gmail_msg">
> Aside:<br class="gmail_msg">
><br class="gmail_msg">
> I've got this working in two forms: a +tools variant on the `sqlite3` port, and a new port called `sqlite3-tools`; I'm feeling like a the +tools variant might be the better way to go, but feedback on this would be appreciated as well.<br class="gmail_msg">
<br class="gmail_msg">
Is there a particular reason why it should be a variant, as opposed to just always building and installing the tools in the sqlite3 port?<br class="gmail_msg">
<br class="gmail_msg">
Whatever you choose, anytime you move a file from being provided by one port to being provided by another port, don't forget to use the deactivate hack in the new port:<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://trac.macports.org/wiki/PortfileRecipes#deactivatehack" rel="noreferrer" class="gmail_msg" target="_blank">https://trac.macports.org/wiki/PortfileRecipes#deactivatehack</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>