simple package tool: for package foo: download foo.tar (tape archive), run configure (if present), run make(1) then make install OR run make uninstall. many scripts since before the 1980's did this - old news.
First you have to see the Apple developer sites and understand that running freeBSD and Linux apps and GNU autoconf code *sometimes* needs porting (to run a compiler - Xcode is not freeBSD compatible but neither is one freeBSD version to another, ditto for linux distros). also know that linux builds without any of those

(
www.kernel.org)
https://developer.apple.com
https://opensource.apple.com
Then note that many freeBSD, Linux apps DO NOT NEED PORTING: they can compile without porting fine. Apps that need porting tend to be the ones that use video, sound, or graphics OR special resources (ie, direct keyboard access, direct file access, something that is Non-Unix).
With Xcode you can quickly develope an iPhone app on iMac and run it on your own phone with visual interaction - or target commandline (bash), or many things: it's good, you aren't going to find free software that is as good. It uses C, also swift and more and isn't %100 bsd or linux or unix compatible (none are even with themselves - a sad legacy they cannot even be compatible with themselves).
freeBSD, Gentoo, Linux From Scratch, many more all started around the same time. "smart package tools". What they do is a simple list.
OK OK BUT WHAT DOES macports DO?? It's rather simple but like anything can get complex "smart" details.
#1 download a list of programs they have source code for (and or prebuilt binaries or scripts and documentation only for) from some site*
* do worry if the site URLS changes and becomes to be "managed" and who is "managing it". who is hacking your binaries and can they be held liable for malware ?
* note macports can download source from anywhere, so it may not be source that they manage: good, because it frees them from being an archive facility, bad because if port suddenly gets deleted there is nothing macports can do about it unless some users revives a new same project
#3 run scripts* that builds the binaries (if necessary) using Xcode. the scripts might do anything - and may even be malicious (depends who uploaded). these usually run make(1), however C, Swift, Java and other can be built using bash(1), and some softwares are scripts and don't need to be build (ie, a TCL script). NOTE: macports keeps pre-compiled binaries and let's you choose to skip the "build phase" - which is fine if you trust the provider and if you can build it if you ever need to alter source.
*
ususally there is a template for each software that lists actions to do before, during, and after build: which includes running bash(1) scripts (see man bash). macports website is very informative about this on it's website: and it's maybe the best packager tool as for "good template keeping". macports can also be used to build iMac Xcode software (ie, for iPhone), though unsure that's popular to do.
* macports is also unbelievably fast compared to older things like "debian apt" (note freeBSD make world is fast, but i hear freeBSD "portage" scripts became convoluted and slow (note some have been newly made)). in otherwords macports does as little as necessary to get the job done very rapidly (like freeBSD make World). in my opinion macports has a very good design - better than the other designs that existed before it was released. the templates avoid lengthy "database searches" before builds and keep what is scripted neat and knowable: and direct to point fast.
#4 run install script OR uninstall script (if available - make sure uninstall is available). (macport's templates allot it to get to this stage, for small apps, almost immediately, not even a blink)
#5 offer a (commandline or gui) scripts that automates some doing the above, such as editing templates, listing ports, you name it
(some softwares need other softwares already build - with thousands of such this becomes a knot of when to build what called "dependencies". the port managers usually resolve thee so that the "depends" are auto included, or provide whatever the differences are between systems that causes the need of porting versus "simply just run cc")
and the smart part is where things get complicated, and complicated is "not good". the upshot is that some people upload "malware" that makes a software no longer do its core functions well while adding "fluff" (or even spy ware) and becomes incompatible with it's own past version. Put say 10,000 of those together that are depending on each other to build: you have a *potential* mess that is only handle-able in today's world by "something like freeBSD make World"