You could be correct. For some years, Portfile authours have been asked to always account for the fact that MacPorts was designed to be cross-platform, and to take steps to make sure the Portfiles remain so.
That's all the "platform darwin" stuff in all the Portfiles and in base. I was just curious if MacPorts actually did work on Linux, and -- it turns out -- it does, with minor surgery. So we're not really "making" it cross-platform; it always has been. I was just more seeing if it truly worked. K On 2020-04-30, at 7:07 PM, Ruben Di Battista wrote: > Can I express a thought about this? :) I hope I won’t result too naive. > > I think the effort of making Macports cross-platform could be destined to > something else. On Linux there's a wide plethora of package managers that > fulfill basically all the needs Macports would fulfill. Just to take > something as an example: > > * Pacman on Arch provides pre-compiled binaries plus the AUR repository of > packages that can be compiled at will (variants are missing, tho) > > * Nix, that I think it's probably the most "correct" package manager > currently available over there. > > * Spack, something like Nix, but optimized for HPC (so cross-compiling, > architecture optimization and so on). > > but I'm surely missing other cool projects. > > IMHO Macports should focus exclusively on macOS. As a contributor to Spack, > Macports (and EasyBuild in the past), I found the TCL based system very hard > to grasp w.r.t. Python-class based packages. That's probably because I'm more > proficient in Python, but I think it's undeniable that Python is an easier > language to pick and gradually learn, and with could also argue on the fact > that an Object-Oriented approach to package description is easier to maintain > (I don't know, I find it easier than the scripts we use in Macports). > > IMHO Macports should focus into potentiating the major selling points it has, > again I pick something I have in mind myself: > > * Native build of libraries and its dependencies > * Compatibility with old macOS versions > * Vast Linux and Unix selection of packages > > and improve some aspects that could be improved: > > * Abandon (not abruptly…) TCL for a more modern language, possibly more > mainstream, that could enlarge the audience of possible contributors for > packages > * Is the core written in C? I even don't know, but if it is, is it needed for > performance reasons? > * Improve compatibility and performances of "Linux-polarized" libraries (e.g. > Inkscape and GTK stuff) > * Provide pre-compiled binaries also for variants to speedup installation for > non-dev users > * Improve community engagement (e.g. switching mailing list to Discourse [it > ships mailing list mode if you prefer to communicate this way, but it would > improve indexing and searchability], IRC --> Matrix, and so on. Just > suggesting...) > > Is there a Roadmap for the development of Macports? Is there somewhere where > I can see what was discussed and which direction Macports has been thought to > take? I would really like to participate, also as a way to learn something > from most of you that are way more skilled then me. I prefer Macports > approach w.r.t. Homebrew, and I'd like that people would be able to evaluate > more fairly the two solutions, maybe avoiding the difficult initial slope > associated to TCL and C-Core. > > Tell me what you think, and sorry if I'm being too naive on some points. I'm > a fairly recent member and reader of the mailing list, I could have missed > some important discussions. > > > _ > -. .´ |∞∞∞∞ > ', ; |∞∞∞∞∞∞ > ˜˜ |∞∞∞∞∞∞∞∞∞ RdB > ,., |∞∞∞∞∞∞ > .' '. |∞∞∞∞ > -' `’ > > https://rdb.is > > On 1 May 2020 at 03:37:28, Ken Cunningham ([email protected]) > wrote: > >> I thought I would start up a short thread on progress with this -- >> MacPorts on Linux. We've long written the Portfiles with this in mind. >> This was done on an Intel system, with the current Ubuntu 20.04. Ubuntu >> 19.10 can be installed in a VM in parallels, and no doubt in other VM >> systems. >> >> Some quick notes: >> >> apt is the built-in package manager, similar to "port". >> >> "sudo apt install" is the same as "sudo port install". >> >> "apt info" is "port info" >> >> "apt-file show" does something similar to "port contents", but the >> software does not have to be installed. >> >> >> After downloading the MacPorts source tarball, and prior to building >> MacPorts, you must install the supporting software that comes already on >> Macs that MacPorts expects to find. >> >> These were installed as: >> >> sudo apt install mtree-netbsd >> sudo apt install tcl8.6 >> sudo apt install curl >> sudo apt install sqlite3 >> sudo apt install gnustep >> sudo apt install libcurl4-gnutls-dev >> sudo apt install libsqlite3-dev >> >> >> my system already had llvm-10 and clang-10 installed, and there was >> already a symlink "port" linking /usr/bin/clang to the selected clang >> binary, in this case clang-10. >> >> Then build and install MacPorts as usual, into /opt/local >> >> ./configure && make && sudo make install >> >> >> Add to your PATH as usual, but on Ubuntu, by editing ".bashrc", adding: >> >> export PATH=/opt/local/bin:/opt/local/sbin:$PATH >> >> >> Adding that PATH to the sudo command is harder -- it doesn't pick it up >> from the above ".bashrc". You have add it to the sudoers command with: >> >> sudo visudo >> >> and then add it to the secure_path >> >> Defaults >> secure_path="/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" >> >> >> There are some differences between Darwin and Ubuntu, and to work around >> some of these that are not already compensated for by MacPorts base, I >> did this: >> >> >> edit macports.conf >> >> sudo gedit /opt/local/etc/macports/macports.conf >> >> and add: >> >> buildmakejobs 2 # or a more appropriate >> number for your processor count >> default_compilers clang # compiler selection is broken, >> this chooses /usr/bin/clang which works best with macport's portfiles >> cxx_stdlib libstdc++ # configure.cxx_stdlib seems >> broken, this fills in appropriate default >> >> >> After that, darwin and ubuntu supply 'sed' in different locations, so >> rather than edit 200 Portfiles, you can do this: >> >> sudo ln -s /bin/sed /usr/bin/sed >> >> >> and then you're up and running. Ports will at least start to build. >> There are a number of hiccups, where the portfile logic does not allow a >> path where the platform is other than "darwin" -- e.g. libuv, but these >> are easy to spot and easy to fix if desired. Some things appear harder >> to fix, like "m4" which I have not yet sorted out. >> >> >> And then you can play around. I don't know if MacPorts on Ubuntu (or any >> other flavour of Linux) will ever be popular, but you can at least get >> started. >> >> >> Best, >> >> >> Ken >> >> >>
