<html><head><style>body{font-family:Merriweather,Arial;font-size:13px}</style></head><body><div style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); "><div style="color: rgb(51, 51, 51); margin: 0px;">Can I express a thought about this? :) I hope I won’t result too naive. </div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">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: </div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">* Pacman on Arch provides pre-compiled binaries plus the AUR repository of packages that can be compiled at will (variants are missing, tho)</div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">* Nix, that I think it's probably the most "correct" package manager currently available over there. </div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">* Spack, something like Nix, but optimized for HPC (so cross-compiling, architecture optimization and so on).</div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">but I'm surely missing other cool projects. </div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">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). </div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">IMHO Macports should focus into potentiating the major selling points it has, again I pick something I have in mind myself:</div><div style="color: rgb(51, 51, 51); margin: 0px;"> </div><div style="color: rgb(51, 51, 51); margin: 0px;">* Native build of libraries and its dependencies</div><div style="color: rgb(51, 51, 51); margin: 0px;">* Compatibility with old macOS versions</div><div style="color: rgb(51, 51, 51); margin: 0px;">* Vast Linux and Unix selection of packages</div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">and improve some aspects that could be improved:</div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">* Abandon (not abruptly…) TCL for a more modern language, possibly more mainstream, that could enlarge the audience of possible contributors for packages</div><div style="color: rgb(51, 51, 51); margin: 0px;">* Is the core written in C? I even don't know, but if it is, is it needed for performance reasons?</div><div style="color: rgb(51, 51, 51); margin: 0px;">* Improve compatibility and performances of "Linux-polarized" libraries (e.g. Inkscape and GTK stuff)</div><div style="color: rgb(51, 51, 51); margin: 0px;">* Provide pre-compiled binaries also for variants to speedup installation for non-dev users</div><div style="color: rgb(51, 51, 51); margin: 0px;">* 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...)</div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">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.</div><div style="color: rgb(51, 51, 51); margin: 0px;"><br></div><div style="color: rgb(51, 51, 51); margin: 0px;">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.</div><div><br></div></div> <br> <div class="gmail_signature"><pre><code>          _   

-.     .´  |∞∞∞∞

  ',  ;    |∞∞∞∞∞∞

    ˜˜     |∞∞∞∞∞∞∞∞∞ RdB

    ,.,    |∞∞∞∞∞∞

  .'   '.  |∞∞∞∞

-'       `’

https://rdb.is

</code></pre></div> <br><p class="airmail_on">On 1 May 2020 at 03:37:28, Ken Cunningham (<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>I thought I would start up a short thread on progress with this --  

<br>MacPorts on Linux. We've long written the Portfiles with this in mind.  

<br>This was done on an Intel system, with the current Ubuntu 20.04. Ubuntu  

<br>19.10 can be installed in a VM in parallels, and no doubt in other VM  

systems.

<br>

<br>Some quick notes:

<br>

apt is the built-in package manager, similar to "port".

<br>

"sudo apt install" is the same as "sudo port install".

<br>

<br>"apt info" is "port info"

<br>

<br>"apt-file show" does something similar to "port contents", but the  

software does not have to be installed.

<br>

<br>

<br>After downloading the MacPorts source tarball, and prior to building  

<br>MacPorts, you must install the supporting software that comes already on  

Macs that MacPorts expects to find.

<br>

<br>These were installed as:

<br>

<br>sudo apt install mtree-netbsd

<br>sudo apt install tcl8.6

<br>sudo apt install curl

<br>sudo apt install sqlite3

<br>sudo apt install gnustep

<br>sudo apt install libcurl4-gnutls-dev

<br>sudo apt install libsqlite3-dev

<br>

<br>

<br>my system already had llvm-10 and clang-10 installed, and there was  

<br>already a symlink "port" linking /usr/bin/clang to the selected clang  

binary, in this case clang-10.

<br>

<br>Then build and install MacPorts as usual, into /opt/local

<br>

<br>./configure && make && sudo make install

<br>

<br>

<br>Add to your PATH as usual, but on Ubuntu, by editing ".bashrc", adding:

<br>

<br>export PATH=/opt/local/bin:/opt/local/sbin:$PATH

<br>

<br>

<br>Adding that PATH to the sudo command is harder -- it doesn't pick it up  

<br>from the above ".bashrc". You have add it to the sudoers command with:

<br>

<br>sudo visudo

<br>

<br>and then add it to the secure_path

<br>

<br>Defaults  

<br>secure_path="/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

<br>

<br>There are some differences between Darwin and Ubuntu, and to work around  

<br>some of these that are not already compensated for by MacPorts base, I  

<br>did this:

<br>

<br>

<br>edit macports.conf

<br>

<br>sudo gedit /opt/local/etc/macports/macports.conf

<br>

<br>and add:

<br>

<br>buildmakejobs            2                  # or a more appropriate  

<br>number for your processor count

<br>default_compilers      clang            # compiler selection is broken,  

<br>this chooses /usr/bin/clang which works best with macport's portfiles

<br>cxx_stdlib                   libstdc++     # configure.cxx_stdlib seems  

<br>broken, this fills in appropriate default

<br>

<br>

<br>After that, darwin and ubuntu supply 'sed' in different locations, so  

<br>rather than edit 200 Portfiles, you can do this:

<br>

<br>sudo ln -s /bin/sed /usr/bin/sed

<br>

<br>

<br>and then you're up and running. Ports will at least start to build.  

<br>There are a number of hiccups, where the portfile logic does not allow a  

<br>path where the platform is other than "darwin" -- e.g. libuv, but these  

<br>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.

<br>

<br>

<br>And then you can play around. I don't know if MacPorts on Ubuntu (or any  

<br>other flavour of Linux) will ever be popular, but you can at least get  

started.

<br>

<br>

<br>Best,

<br>

<br>

<br>Ken

<br>

<br>

<br>

<br></div></div></span></blockquote></body></html>