Welcome! This is the Ruby Macports page of the MMINAIL.

Note. This page has explicit access to the local jQuery library as well as to a local complimentary working (.js) file.

More to come ...

So, ya wanna upgrade Ur system Ruby AND learn a little Homebrew, heh?

Via Jekyl, no doubt.

This is a very sensitive area of juxposition for the Internet, the Coding Community, and for Global Intelligence in general.

"¡Cuidado! You must tread lightly, and carry a big Unix stick! ~ Steve Jobs"

Especially when working with your 'fixed-in-concrete' system Ruby and the dreaded entrenched Macports.

Macports pre-compiles Port(s) into Binary Archives (BA), or Port files called MacPort BA(s) and then stores the finished products on a remote server.

The finished MacPort BA(s) are then tagged eligible for download via Macports dot org.

In addition, MacPort BA(s) in (.tbz2) format are also created both locally and automatically in the /opt/local/var/macports/software/ subdirectory of your Macports initial ( default ) install or in your Macports 2nd ( Macports241 ) install whenever port installs a Port file.

Caveat. The MacPort BA(s) can only be used on a target system running Macports.

For example, a MacPort BA cannot be installed on a system that relies solely upon Homebrew, or the Fink Project.

The build phase of an install is usually the phase that takes the longest amount of time to run in terms of milliseconds.

Macports allows a MacPort BA and an accompanying set of utilities to skip the build phase of an install and to begin installation of an application right after the 'destroot' phase.

As a result, applications need not be compiled when installing to on a target system capable of handling MacPort BA(s).

For this capability, the administrator must download and install Macports onto the development machine.

More to come ...

Binary Packages, or BP are stand-alone Binary installers that are pre-compiled.

And, as such ... do NOT require an accompanying set of Macports utilities.

A 2nd install of Macports on your development machine will give you the capability of locally creating BP ... For distribution (if licensed).

And, thereby avoiding conflicts with Port files on systems that already have an initial default copy of Macports installed.

In addition, a utility exists via Macports should you wish to distribute your software via (.dmg) rather than (.pkg) formats.

To perform a 2nd install of Macports on your development machine that is separate from the initial default /opt/local/ install, focus on the following two (2) command switches.

Create a second App trigger ...
1
--with-applications-dir

In the Applications folder.

And,

Create an Alt directory ...
1
--prefix

To Install Into.

Note. The --prefix switch accommodates the alternative directory.

Whereas, the --with-applications-dir switch avoids conflict with your already existing local Applications/MacPorts folder.

Rule. Stay with the opt directory of your machine root, and build a 2nd install of Macports in an alternative subdirectory.

For example, /opt/Macports241/.

Why fuss with another instance of Macports?

Analysis. When the issue of solving why your local Jekyll server hangs when given the previous accurate start command of ...

Jekyll Start Command ...
1
jekyll serve --watch --baseurl ""

Was working fine!

Prior to the attempted upgrade to Ruby 2.4.0 via Homebrew ...

Conclusion. The "fuss" Becomes paramount to further development.

Navigate via the Finder to the location of your preferred and separate 2nd install of Macports ie.) /opt/Macports241/.

When you have arrived at your destination, right-click over the subdirectory name in order to expose the Services tab.

Now, select a 'new Terminal window at folder' to open up the Terminal program.

Before the administrative instant User can unpack a Port file ... ( In this case Macports base ver 2.4.1 ), the BA must be downloaded.

The following code must be executed in the Terminal in order to download the requested Port file from Macports, as follows:

Download Macports base ver 2.4.1
1
curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.4.1.tar.bz2

Programatically!

Next, unpack the BA file with the following Terminal command ...

Unpack n Un-b-zip! ...
1
tar xf MacPorts-2.4.1.tar.bz2

Pronto! Andele!

This places an exploded subdirectory of name same ie.) MacPorts-2.4.1 in the /opt/Macports241/ folder.

    Whoosh! ( Interlude )

Before we can start building a 2nd instance of Macports on your local development machine ...

We must perform something that appears to be counter-intuitive, but once achieved illuminates the pathway to the success of all of your many hours (and, days?) of learning, expanding, and troubleshooting.

¡Recuerde!. In order to pull this off, we must depart from our standard working User and become an administrative instant User ... on the same machine!

The binary path(s) of the initial install /opt/local/bin:/opt/local/sbin: must be commented out from the instant User $PATH variable.

Why? Because the locations the export statements represent must not be present during the Build of the 2nd instance of Macports.

Once we make it to a successful install of a 2nd instance of Macports, we can then upgrade both Ruby to version 2.4.0 and Rubygems to 2.6.11 via another separate Build of a BA, and a call via upgraded gem.

Rather than attempting to install another copy of Ruby through Macports ( this is what hung the local Jekyll server in the first place! )

Or, through Homebrew ( does Homebrew even have their Ruby-24 BA back on the bottle rack again? )

Or, through RVM ... Who was, by the way, feeding off of the error codes generated by Homebrew!

A conspiracy to rig the market in favor of Homebrew? Naw, the RVM boys were just being cautious. Short of allowing the install, the RVM bots were quite accommodative.

Ya know ... Macports has already countered with a scare claim of their own against the /usr/local/ subdirectory at their online documentation site.

( As opposed to the Macports preferred subdirectory of choice ... /opt/local/ ).

Yep! Created a whole sub-section at their menu of directions to house the scare claim against /usr/local/.

What? Are you all Trump voters? Or, something? Out there in coding land?

Back to the Binary Paths! We've got more work to do there!

Simply right-click over the hidden dot bash underscore profile file located in the root directory of the instant administrative User ... And, open the file for editing in TextEdit.

Once open, simply prepend the export statement that contains a reference to the above Macports binary path(s) with a keyboard 'hash' symbol, or #.

Note. The export statement was originally placed in the dot bash underscore profile file at the time of the initial install of Macports.

After placing the 'hash' symbol, or # appropriately at the front of the export statement ... ( in order to comment the export statement out ), save and close TextEdit.

Now that the instant administrative User's dot bash underscore profile file has been corrected, we must now rebuild the $PATH variable.

First, after editing the the hidden dot bash underscore profile file ... The Terminal program must be 'rebooted'.

• Close the Terminal Window,
• Close the Terminal Program,
• Re-open the Terminal Program.

To perform a rebuild of the $PATH variable, at the Terminal prompt enter the 'path_helper' command, as follows:

The path_helper Command ...
1
/usr/libexec/path_helper

Use the full path to the command.

A subsequent echo of the $PATH variable should now reveal an absence of any 'opt' type subdirectories in the administrative instant User path.

Look for opt(s) ...
1
echo $PATH

No opt(s) allowed!

Be sure you have navigated via the Finder to the location of your unpacked tbz2 copy of Macports ver 2.4.1.

Now right-click over the accepted subdirectory to open up the Services tab, a new Terminal window at folder.

Have Macports set the directory of your --prefix switch to the target destination of your 2nd instance with the following Terminal statement.

The Target Destnation
1
MP_PREFIX=/opt/Macports241

Configure, Make, Install

Have Macports set your machine's Applications folder to receive a separate, 2nd Macports install folder named 'Macports241'.

Note. Because this command statement will also start the configuration process of the 2nd instance ... You will need to perform this step as a super-user.

Compiling The Code ...
1
2
sudo ./configure --prefix=$MP_PREFIX  ➡️  
    --with-applications-dir=$MP_PREFIX/Applications

Follow along w the machine ...

A verbose, line-by-line and blow-by-blow compilation will be printing to the Terminal window.

For example, here is an unusual looking line from the compile timeline ...

GNU Step Foundation Library
1
2
3
4
configure: WARNING: GNUSTEP_SYSTEM_ROOT ➡️ 
    is not defined in your environment, ➡️  
    preventing the use of ➡️  
    GNUstep's Foundation library

Sub Apple Foundation Library

Until you realize the GNU Foundation Library closely resembles Apple's Cocoa (formerly NeXT's OpenStep) API.

And, now you see the compilation process opted for the Mac OSX Sierra Xcode Command Line Tools ver 8.3 default to the Apple Foundation Library.

Next, we must 'make' the now compiled 2nd instance by simply typing the command make at the Terminal window as a super user.

Only super-users make ...
1
sudo make

Be a super-user!

Note. There were (50) warnings during the make with basically the same message.

RE: SysCall deprecated ... Please use a supported interface

For more information, including the Terminal report of the make section in question ... See the private GIST located at GitHub.

Ok, it's time to install what we've made with the following command statement.

From the Terminal,

Install the Make
1
sudo make install

Local admin su doer

Finally, after a successful build, add the location to the 2nd instance bin ie.) /opt/Macports241/bin to your administrative instant User dot $PATH variable by opening the bash underscore profile file once again.

Include the following export statement in the file ...

Add a new line
1
export PATH="/opt/Macports241/bin:$PATH"

Save and close

Keep the original two binary paths from the initial install of Macports commented out by the keyboard 'hash' symbol, or #.

Now that we have changed the administrative instant User dot bash underscore profile file for a second time ...

Once again, we must reboot the terminal for the changes to take effect.

• Close the Terminal Window,
• Close the Terminal Program,
• Re-open the Terminal Program.

Recall to perform a rebuild of the $PATH variable ...

Remember to enter the following line of code at the Terminal prompt.

Enter the path_helper command, as follows.

Use every time after an edit
1
/usr/libexec/path_helper

To rebuild the $PATH variable

Similar to before ...

A subsequent echo of the $PATH variable should now reveal the inclusion of a single 'opt' type subdirectory ie.) /opt/Macports241/bin in the administrative instant User path.

Congratulations! You have successfully installed a 2nd instance of the MacPorts system!

To get the accompanyng Port file(s), if any ... And, to update the system, run the following line of code ...

Ensure Macports is fully functional
1
sudo port -v selfupdate

Under this instance.

Returns,

MacPorts base is already the latest version ...

The ports tree has been updated.

To ensure all installed Port files have been upgraded to the Macports max ...

Run the following command from the Terminal prompt as a super-user, as follows:

Upgrade all Port files.
1
sudo port upgrade outdated

aka Binary Archives

Returns,

Nothing to upgrade.

For further review,

Please read 'man port', the MacPorts guide.

Also, please read the Macports Wiki.

    Finito!