Heimdal Compilation/Install Error

[astyle]

Actually, the way I have written my stuff, it invokes make config-conditional - so when a new port is requested for a target, or an existing one got additional options after a git pull,then the options box does pop up before the dependencies are collected.
And I had that "error, circular dependency" detection scripted in earlier versions, but it seems currently good enough when it just starts to build, and then says "hey, I cannot deploy, because not all ports are built; this and this and this port did not reach the point where all dependencies were completed".

(BTW: currently my source repo is not steadily available, because I have an ugly bug in the IPS; it says EAFNOSUPPORT and crashes as soon as one switches to STARTTLS on a IPv6 mail connection.)

PMc , your story suggests to me that there needs to be a clean separation between detection of circular dependencies and compilation errors for dependent ports. The former shows an infinite, closed loop of dependency resolution that needs to be broken by changing the knobs somewhere. The latter actually has a stop condition that is independent of circular dependencies.

 

[PMc]

PMc , your story suggests to me that there needs to be a clean separation between detection of circular dependencies and compilation errors for dependent ports. The former shows an infinite, closed loop of dependency resolution that needs to be broken by changing the knobs somewhere. The latter actually has a stop condition that is independent of circular dependencies.

That may be the case, yes. But in the way I did approach the task, this separation did not bother me. I am doing two things:
1. look at all the desired ports, make sure their options are set as desired, and gather their dependencies. Repeat doing that recursively, and write it all into a list.
2. Take that list, create a second (in-memory) list of those ports that are already present in pkg-format, and figure out what can be built next. If prereqs are needed, install them, then build the port. On success move it from the first to the second list. When the build fails, mark it as failed. (For the next port, zfs-rollback all that is not needed, then approach anew - that's my imperative, because I want reproducible builds that do not magically decide on features dependent on what is already present on the system.)

Neither 1. nor 2. can get into an infinite loop. 1. will notice that dependencies have already been gathered (which happens always when prereqs are needed for multiple ports), and 2. will just stop when nothing can be done anymore. Then somebody has to look into the matter, and that's the case anyway.
(I think there is also s report at the end, which ports have failed to build, and which had unreachable dependencies.)

 

[astyle]

That may be the case, yes. But in the way I did approach the task, this separation did not bother me. I am doing two things:
1. look at all the desired ports, make sure their options are set as desired, and gather their dependencies. Repeat doing that recursively, and write it all into a list.
2. Take that list, create a second (in-memory) list of those ports that are already present in pkg-format, and figure out what can be built next. If prereqs are needed, install them, then build the port. On success move it from the first to the second list. When the build fails, mark it as failed. (For the next port, zfs-rollback all that is not needed, then approach anew - that's my imperative, because I want reproducible builds that do not magically decide on features dependent on what is already present on the system.)

Neither 1. nor 2. can get into an infinite loop. 1. will notice that dependencies have already been gathered (which happens always when prereqs are needed for multiple ports), and 2. will just stop when nothing can be done anymore. Then somebody has to look into the matter, and that's the case anyway.
(I think there is also s report at the end, which ports have failed to build, and which had unreachable dependencies.)

The issue that I'm seeing here is that make is not that smart. It will happily compile everything it can first, then enter the dependency loop, and keep looping, unable to get out. I'd think the loop needs to be detected BEFORE compilation starts. PMc , your item #2 seems to break the loop by running # pkg install dependencies, rather than compiling dependencies. The build is not gonna fail, it will just keep looping for missing dependencies.

 

[cy@]

There certainly is. Query the dependencies of the dependent ports, recurse and see that the graph loops back.
But that doesn't belong to the responsibilities of a single port's building process.

That was my point.