<div dir='auto'><div>Hello all, <br><div><br><div class="elided-text">On Feb 28, 2019 4:21 AM, Mojca Miklavec <mojca@macports.org> wrote:<br type="attribution"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Dear Arghya,
<br>

<br>
Welcome in the MacPorts community!
<br>

<br>
On Wed, 27 Feb 2019 at 17:37, Arghya Bhattacharya
<br>
<arghya.b@research.iiit.ac.in> wrote:
<br>
>
<br>
> Greetings all,
<br>
>
<br>
> I'd like to contribute to MacPorts.
<br>
>
<br>
> I've gone through the ideas and Auto-detection of build dependencies seems interesting to me.
<br>
>
<br>
> I have queries regarding the same:
<br>
> - Is the project in reference to changing "port reclaim", more specifically change port reclaim to not delete build dependencies?
<br>

<br>
These two are not related, but both tasks could be worked on. They
<br>
potential mentor for any of those tasks would be Marcus, so I hope
<br>
that he jumps in with more relevant answers.
<br>

<br>
I assume that you took auto-detection of build dependencies from our
<br>
list of ideas, and the "port reclaim" from a recent discussion on the
<br>
mailing list?
<br>

</p></blockquote></div></div></div><div dir="auto">-> Yes, I went through the archives hoping to find more insight into the projects from the discussions. </div><div dir="auto"><br></div><div dir="auto">-> Would  Port reclaim be a separate project in that case? <br></div><div dir="auto">Seems like an extension of computing build dependencies to me. Maybe I'm missing the point here.</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
(1)
<br>
Unless I'm mistaken, detection of build dependencies is probably not
<br>
meant strictly as "only build dependencies", but as any dependency
<br>
that the port might have.
<br>

<br>
Software would happily build against any dependencies you already have
<br></p></blockquote></div></div></div><div dir="auto">-> Any Port would have compulsory dependencies and optional dependencies. </div><div dir="auto">So the issue is with detecting which optional dependencies are being used? </div><div dir="auto">How does the problem persist with compulsory dependencies too? Aren't they listed in the Port configuration files?</div><div dir="auto"><br></div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
installed, but:
<br>
* it takes quite a while to figure out which dependencies were in fact used</p></blockquote></div></div></div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
* you might end up with incomplete list of dependencies since you
<br>
never get any feedback if you forgot something; you only figure that
<br>
out on Travis/Buildbot </p></blockquote></div></div></div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
* many dependencies link opportunistically: they'll be used if
<br>
present, and skipped if absent.
<br></p></blockquote></div></div></div><div dir="auto">-> these are the dependencies to install the Port or the ones needed to run them?</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
We would want the "port" command to automatically report which
<br>
dependencies were used during the build (either build dependencies
<br>
like pkg-config or libraries, ...)
<br></p></blockquote></div></div></div><div dir="auto">-> By keeping track of what files are accessed during build ?</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
Trace mode (selected by "-t", so: "sudo port -v -t install") already
<br>
reports if the installation tried to access some files (but the port
<br>
is not allowed to actually access them during the build). Here the
<br>
logic would be slightly different: you would not hide the files based
<br>
on declared dependencies, but list the dependencies based on accessed
<br>
files.
<br>

<br>
(2)
<br>
We recently discussed the issue that "port reclaim" removes build
<br>
dependencies. This would be also nice to fix, yes.
<br></p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">-> So, if AutoDetecting & storing all dependencies of a port becomes a method attribute of the Port. Then this would be as trivial as accessing the list on a trigger of port reclaim?</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
> - Auto-Detecting the build dependencies would essentially mean replicating the behavior of "port deps" or "port info"?
<br>

<br>
No, "port deps" uses the information that's already provided in
<br>
Portfiles to list the dependencies. The idea of automatically
<br>
generating the list of dependencies means that "port" would need to
<br>
check which files were accessed during the build phase and reconstruct
<br>
the list of dependencies from there.
<br></p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">-> This makes sense. Just looked at the scripts for deps and I understand why this wouldn't work.</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
> - How should I go about contributing to the code?
<br>

<br>
We may need to come up with some "How to start contributing" manual
<br>
anyway :), but I'll try to explain a few ideas shortly (I hope to
<br>
write more later).
<br></p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">-> I've used the git method of install, updated head of my installation to my fork of port-base. </div><div dir="auto">I just don't find any instructions on how I can compile my changes to the tcl scripts so I can test the commands with my changes ?</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
There are two separate questions:
<br>
- How does one learn how to contribute to MacPorts.
<br>
- What we expect from GSOC candidate students.
<br>

<br>
The answer to the second question is that we would like to see
<br>
students show the capability of understanding the problem and being
<br>
able to contribute, even if starting with some trivial commits.
<br></p></blockquote></div></div></div><div dir="auto">-> Sure, I'll pick some tickets up and try to solve them :)</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
By far the easiest way to start contributing is by perhaps updating an
<br>
outdated package you use (port livecheck installed), or write a
<br>
package for a new one, get familiar with how MacPorts works etc. Our
<br>
bug tracker is here:
<br>
    https://trac.macports.org/wiki/Tickets
<br>
but sadly we lack identifiers for "easy to solve", and most issues in
<br>
base are not something to be solved with two lines of code (tickets
<br>
with requests for updates are probably easier).
<br>

<br>
I hope that others will give you some more guidance into base hacking.
<br>

<br>
Mojca
<br>
</p>
</blockquote></div><br></div><div dir="auto">Regards</div><div dir="auto">Arghya</div></div></div>