I suggest splitting the Readme.md file into two or more

[carlosdelfino]

I suggest splitting the Readme.md file into two or more Install.md files, one for each platform, since not all use MAC, for example I use Windows with Cygwin and Mac with MacPorts.

Something like Install.mac.md install.win.md without many details of variants since it is an infinity.

And finally suggest not induce third parties to compile the site and publish this compilation, so just keeping a compilation in the main repository ..

[ilg-ul]

one for each platform

unfortunately I have no idea how this works on windows.

so, if you think useful to document the steps required on Windows, no problem, but don't expect me to do it.

Mac with MacPorts

no problem, please feel free to continue to use MacPorts, if you like it.

the point of a separate Homebrew install is exactly this, to isolate it from your existing setup. run the steps I presented there and you'll end up with a new folder that contains everything needed and will not interfere at all with the rest of your system.

FYI, I have several separate Homebrew instances and several separate MacPorts instances, none in the current path, so with zero impact on normal operations. for the future I plan to migrate everything to Homebrew.

[carlosdelfino]

Well, once we having defined the structure of files and directories, I same create for Windows, I agree with that.

I have not had much success in using macports and homebrew together, and do not know how to do it, let alone multiple instances of each.

even in the windows, I'm having trouble doing it with Cygwin and other native Windows tools.

Round here I prefer to keep only two workstations and configured each with its best.

Well, regarding the structure of the project, I wait your settings, so we set, I beginning the translation.

:)

[ilg-ul]

using macports and homebrew together, ... multiple instances of each.

it is very simple: install each one in a separate folder and DO NOT add this folder to the path.

the Homebrew manual insists on installing in /usr/local and keeping it in the path; by all means, don't do that!

follow my instructions by the book and you should end up with a separate folder /opt/homebrew-jekyll3.

[ilg-ul]

Cygwin

I would not recommend it at all. as far as I heard, msys2 is a more elaborate solution.

somehow related, for building windows applications on unix, mingw-w64 is the solution, I use it to build openocd, qemu, make, and all other tools.

[carlosdelfino]

Good Tip.

As soon as possible I will remove the cygwin and test msys2, I use cygwin think over 10 years, I got to test a few years the mingw but missed linux tools. But today I think hé time to leave the cygwin background.

[ilg-ul]

just curious:

• installing Ruby on Windows is not enough for Jekyll? is it really necessary to add extra tools, available only in Cygwin/msys2?
• would it be possible to install e separate instance of Ruby on Windows, dedicated to Jekyll, and not interfering with other applications?

and a separate question:

• is gem via bundle able to install and keep track of multiple versions of a gem? in other words, in a public Ruby instance, used for multiple applications, what happens if Jekyll requires (via Gemfile.lock) a gem version and another application requires another version? are they both installed in separate folders?

the reason I prefer to keep separate Homebrew instances is exactly to be absolutely sure I do not have to deal with such interactions.

[ilg-ul]

msys2 vs mingw-w64

one important notice: msys2 and mingw-w64 are completely different things.

msys2, like cygwin, is a unix-like environment that runs on windows.

mingw-w64 is a cross compiler that produces .exe files that (together with some DLLs) run standalone on any windows, even if msys2/cygwin/etc is not installed.

inside msys2, like inside cygwin, there is also a compiler and a set of libraries that allow to build .exe applications, but these applications usually require msys2 (respectively cygwin) to be present, which is a big problem when distributing binary applications (like openocd, qemu, etc). this is the reason why I use mingw-w64 for my builds (it runs very well from a docker container).

[carlosdelfino]

Well, let's start at Cygwin, I initially chose because I wanted the Linux tools on Windows, I was born in Xenix and use Linux since 1996, but Windows has tools that I have in Linux, and I became hostage Cygwin with time because I started to play with the GCC and then the AVR-GCC and then the GCC-none-EABI, not to mention that it seemed to some more fashionable time to have everything in one place with the same layout. I think it all started with Linux From Scratch, needed an environment to build my first boot and kernel.

But today I have missed some tools, I stay only with Mac or Linux mount a station again to me, but the time does not allow. I miss another computer on the bench and I have no hard disk space for a virtual machine.

Well, I will test the msys2 as soon as possible, to know it and the difference with the migw I understand, already suspected.

Maybe I remove all development Cygwin and install native versions in Windows, but it will take time, I will at another time my focus is only the translation of documents and articles, I try to keep such a focus this semester.

[carlosdelfino]

About Jekyll, Ruby, Bundler and Cygwin.

As I was using Cygwin, I chose to keep the Ruby on Cygwin, but it is not showing a good choice, and I intend thus to finish this phase of translations restructure my development environment, but now the focus is to finish the first stage of translations.

From the little I know of Ruby, the Bundler is a jail that lets you manage the dependencies of gems with the correct versions, you can not only determine the correct version, but can also determine whether a gem should be present or not depending on the environment used.

see for example the case of WDM which is indicated to be used in Windows but not on Mac or Linux.

I am an apprentice in Ruby, only use Ruby for Jekyll, is a language that does not attract me much, I prefer the node.js, so I opted to use the GitBook for books and manuals, which let suggestion for a future migration "user-manual" as a project of the site.

[ilg-ul]

no problem, if Cygwin works for you, continue to use it.

what I wanted to say is that in my projects, if I have to suggest others to install various tools to perform the builds, I do my best to educate users to use the best and up-to-date tools, and avoid as much as possible to suggest old and outdated tools.

to conclude, feel free to use any tools you like.

if you want to share any experience with these tools, for any purposes, you can post them in the project forum.

if you'll ever have a solution to install a separate Ruby instance dedicated to Jekyll, we'll split the README content into several platform specific files.

for now, as you mentioned, let's focus on content.

[carlosdelfino]

ok. :)