Moving this to macports-users, as it's quite off-topic for the ticket.
You may have to subscribe to the list to respond.
https://trac.macports.org/wiki/MailingLists
On Jun 19, 2015, at 3:59 PM, MacPorts wrote:
> #47755: Broken symlink left by select code when selected port is
> deactivated causes poppler and other ports using aclocal to fail during
> configuration.
> ---+
> Reporter: lukasz@… | Owner: macports-tickets@…
> Type: defect| Status: new
> Priority: Normal| Milestone:
> Component: base |Version: 2.3.3
> Resolution:| Keywords:
> Port:|
> ---+
>
> Comment (by m74z00219@…):
>
> Replying to [comment:19 ryandesign@…]:
>
>> Replying to [comment:18 m74z00219@…]:
>>
>>>
>>> I tried removing the symlink to wxwin.m4, but install still fails.
>>> I think my problem extends to the fact that I've been fooling around
>>> with git (from macports). The log refers to a list of items that were
>>> not installed by Macports...or at least not registered to have been
>>> installed by Macports.
>>>
>>> Actually, after uninstalling some git repo related stuff (sudo make
>>> uninstall), I was successfully able to install encfs -- thanks!
>>>
>>> Is this typical of git repo project installations to interfere with
>>> Macports?
>>
>> The method of software distribution (i.e. from a git or hg or svn or
>> cvs or bzr repository, or from a tarball download) should have no
>> bearing on whether a project interferes in some way with MacPorts.
>> You'll have to be more specific about the problem you're experiencing,
>> if you still need help with it, but it sounds like it's not related to
>> this ticket, and if it's something you're doing outside of MacPorts
>> (using "`make`" for example) then it sounds like it's not related to
>> MacPorts.
>
> While my original ticket (#48052) was rightly marked duplicate, it
> turned out that my inability to install encfs was two-fold -- the
> broken / unregistered symlink from wxWidgets and Git project
> compilations.
>
> You're right on that it was the "making" that caused the issue, so in
> certain respects the conflicting software was my fault.
It's still not at all clear what you did. Did you "make install"
something to the MacPorts directory tree? Did you tell the build where
to install its files, or did it do so of its own volition?
> That said, Macports does host a Git port, which is a software
> distribution platform. There is no indication / warning that Git
> projects involving compilation may install libraries that might
> interfere with Macports.
I don't think you understand what Git is.
Git is not a "platform" by any reasonable definition of the word. It's
a version control system: a tool that allows content creators (usually
software developers) to organize and distribute their work (usually
source code). Git has nothing to do with compiling or installing; as
Ryan already said, a project's choice of version control does not affect
how it builds and works (Git submodules and such notwithstanding).
A project that interferes with MacPorts will do so whether you retrieve
it with Git or Mercurial or Subversion or curl or wget or Safari or lynx
or floppy disk.
> Maybe it is warranted that Macports add a disclaimer to the Git port?
This would not be warranted. We might as well add such warnings to any
port that allows you to download a file or compile a binary.
> Or, perhaps a guide to preventing conflicts with Macports when
> building Git projects?
I don't know how we could do this in a meaningful way. It would be like
writing a guide to preventing a word processor from overwriting files in
your home directory. Either (a) you're telling the program to overwrite
those files yourself, in which case you just have to stop, or (b) the
program is doing so on its own, in which case you can't do much, other
than file a bug report and stop using the program.
vq
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
