> Is "sqlite3 CLI shell" the 'sqlite3' binary that is already installed by the
> sqlite3 port?
Yes. So as a separate port I would skip that binary and provide only sqldiff
and sqlite3_analyzer.
> I would think a separate port (or subport) would be better. A non-default
> variant would not be
> 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:
>
> https://trac.macports.org/wiki/PortfileRecipes#deactivatehack
Thanks for pointing this out.
I added this, but I
On Jan 12, 2017, at 22:10, Aaron Madlon-Kay wrote:
> > 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?
>
> That's the most convenient solution to be sure. I wasn't sure if, perhaps,
> sqlite3 is such
Thanks for the feedback, Ryan.
> 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?
That's the most convenient solution to be sure. I wasn't sure if, perhaps,
sqlite3 is such a prolifically depended-upon port
On Jan 12, 2017, at 01:58, Aaron Madlon-Kay wrote:
>
> Hi all. I was hoping to get some advice:
>
> I want to make the sqlite3-tools package available via MacPorts (binaries
> available at https://sqlite.org/download.html); this package contains three
> binaries: sqlite3 CLI shell, sqldiff,
