Re: Discussion of idea: Auto-detection of build dependencies [GSoC][Application Process]

[arghya bhattacharay]

Hello all, 

On Feb 28, 2019 4:21 AM, Mojca Miklavec <mo...@macports.org> wrote:

Dear Arghya,

Welcome in the MacPorts community!

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

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

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

-> Yes, I went through the archives hoping to find more insight into the projects from the discussions. 

-> Would  Port reclaim be a separate project in that case? 

Seems like an extension of computing build dependencies to me. Maybe I'm missing the point here.

(1)
Unless I'm mistaken, detection of build dependencies is probably not
meant strictly as "only build dependencies", but as any dependency
that the port might have.

Software would happily build against any dependencies you already have

-> Any Port would have compulsory dependencies and optional dependencies. 

So the issue is with detecting which optional dependencies are being used? 

How does the problem persist with compulsory dependencies too? Aren't they listed in the Port configuration files?

installed, but:
* it takes quite a while to figure out which dependencies were in fact used

* you might end up with incomplete list of dependencies since you
never get any feedback if you forgot something; you only figure that
out on Travis/Buildbot 

* many dependencies link opportunistically: they'll be used if
present, and skipped if absent.

-> these are the dependencies to install the Port or the ones needed to run them?

We would want the "port" command to automatically report which
dependencies were used during the build (either build dependencies
like pkg-config or libraries, ...)

-> By keeping track of what files are accessed during build ?

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

(2)
We recently discussed the issue that "port reclaim" removes build
dependencies. This would be also nice to fix, yes.

-> 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?

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

No, "port deps" uses the information that's already provided in
Portfiles to list the dependencies. The idea of automatically
generating the list of dependencies means that "port" would need to
check which files were accessed during the build phase and reconstruct
the list of dependencies from there.

-> This makes sense. Just looked at the scripts for deps and I understand why this wouldn't work.

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

We may need to come up with some "How to start contributing" manual
anyway :), but I'll try to explain a few ideas shortly (I hope to
write more later).

-> I've used the git method of install, updated head of my installation to my fork of port-base. 

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 ?

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

The answer to the second question is that we would like to see
students show the capability of understanding the problem and being
able to contribute, even if starting with some trivial commits.

-> Sure, I'll pick some tickets up and try to solve them :)

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

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

Mojca

Regards

Arghya