Gem build documentation for new gems?

Dr Brain? Anyone?

Formerly happy-path gem specs are now issuing warnings for me:

WARNING: no rubyforge_project specified
WARNING: deprecated autorequire specified

Google results for “gem build documentation” start off with Hoe. :-\


Giles B.

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

On Jan 12, 2008, at 07:57 AM, Giles B. wrote:

Dr Brain? Anyone?

Formerly happy-path gem specs are now issuing warnings for me:

WARNING: no rubyforge_project specified

So, you didn’t specify a rubyforge_project in your gemspec. You are
on seven projects on RubyForge, I imagine your gem belongs to one of
them.

WARNING: deprecated autorequire specified

You specified autorequire which is a deprecated attribute. You should
stop specifying it.

Google results for “gem build documentation” start off with Hoe. :-\

hrm, ri Gem::Builder is short documentation too.

On 1/12/08, Eric H. [email protected] wrote:

So, you didn’t specify a rubyforge_project in your gemspec. You are on
seven projects on RubyForge, I imagine your gem belongs to one of them.

WARNING: deprecated autorequire specified

You specified autorequire which is a deprecated attribute. You should stop
specifying it.

And it should be documented.

This is outdated:
http://docs.rubygems.org/read/chapter/20#page85

Look at platform:
http://docs.rubygems.org/read/chapter/20#platform

it’s even given me an example with Gem::Platform::Win32

On 4/6/08, Phillip G. [email protected] wrote:

|
Bitter? Me? Never…
Hahahaha

Yeah, there are some people like that writing open source software.
Fortunately it doesn’t happen everywhere. OpenBSD for example, they do
not add any feature if it is not documented.

I have checked the page again, it was generated in 2005. This is
unacceptable. Being gratis or open source is not an excuse.

goes back finding out how to cross-compile Ruby extensions for MinGW-Ruby

Why not compile natively on Windows?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerardo S. Gómez Garrido wrote:
|
| And it should be documented.
|
|
| This is outdated:
| http://docs.rubygems.org/read/chapter/20#page85
|
| Look at platform:
| http://docs.rubygems.org/read/chapter/20#platform
|
| it’s even given me an example with Gem::Platform::Win32

Welcome to the world of Open Source Software, where ideology replaces
good practices, source code is called documentation, and praise be unto
UNIX, the Best Thing Evar to come out of Bell Labs, and the command line
is its messiah.

Bitter? Me? Never…

goes back finding out how to cross-compile Ruby extensions for
MinGW-Ruby


Phillip G.
Twitter: twitter.com/cynicalryan

Will I be pretty? Will I be rich?
~ – K. Sirra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAkf5O5IACgkQbtAgaoJTgL+oPQCY9x8qr6gPSy8EClsGbEviKKaA
dQCeL9OKpHKZelIcYAIlesZ8/w3dKN8=
=3in8
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerardo S. Gómez Garrido wrote:

| Yeah, there are some people like that writing open source software.

If it were only “some”, my life would be easier.

| Fortunately it doesn’t happen everywhere. OpenBSD for example, they do
| not add any feature if it is not documented.

And we (all of us, I’m guilty of providing insufficient documentation
myself) need to strive to set the bar as high as possible.

| I have checked the page again, it was generated in 2005. This is
| unacceptable. Being gratis or open source is not an excuse.

However, I’m certain the RubyGem developers (or maintainers of any
documentation), will be grateful for patches or new documentation.

And to put my money where my mouth is, I’ll write up a bare-bones
tutorial on how to build a gem, and send it off to the Rake folks (I’m
using Rake to generate my gems and packaging, so cut me some slack,
will you. :P)

|
| Why not compile natively on Windows?

Setting up a MinGW/MSYS environment is a bit of a hassle, especially if
you want GCC 4, since the MinGW32 folks lag behind on that.

However, I’ve asked myself that same question. Trouble would be to
define the Ruby environment for building extensions for things like
GTK+/GNOME2, which are available pre-compiled at the moment (storage of
header-files, how mkmf works, what needs to be handled, etc. In short, I
don’t know the scope of this tangled mess just yet, and can’t start
unraveling the threads).

The up-shoot is, that I was able to install the tmail extension with
Luis’ installer recipe (and tmail compiled itself happily. I have no
idea if it works, though :P), which makes me wonder if it isn’t possible
to distribute a Ruby version which comes with a compiler environment for
developers, with an option to build a Ruby redistributable (sort of like
the Visual C runtime, or a Java VM) for deployment, and/or have a Ruby
distribution for end-users only, who want to run pre-defined scripts,
they get handed by somebody (An analogue of the Java world: A Ruby SDK
ala the JDK for developers, and a Ruby RE ala the JRE for end users).

In principle this is possible, as Rubyscript2exe, and exerb demonstrate.

If anybody has an idea how to tackle the problem of redistributing
extensions, I’d be grateful as heck.

Sadly, I’m no C/C++ guru, so I’m not able to dig into C code, where
needed. And I’m not that much of a Ruby programmer, that I can read Ruby
as second nature, parsing it in my head. :frowning:


Phillip G.
Twitter: twitter.com/cynicalryan

You summoned me, Captain? asked T. Earl Grey, hotly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf6KsAACgkQbtAgaoJTgL9WagCfYaRKNREi1qs2bJYmQjAnwswn
HaQAoKRWIjIeFqKFSLBz4QNE7Pq78Ab3
=xd+W
-----END PGP SIGNATURE-----

On 4/7/08, Phillip G. [email protected] wrote:

| Fortunately it doesn’t happen everywhere. OpenBSD for example, they do
| not add any feature if it is not documented.

And we (all of us, I’m guilty of providing insufficient documentation
myself) need to strive to set the bar as high as possible.

Indeed. I do my share also.

|
| Why not compile natively on Windows?

Setting up a MinGW/MSYS environment is a bit of a hassle, especially if
you want GCC 4, since the MinGW32 folks lag behind on that.

Have you tried the latest attempt from Luis L.? You can easily
build msys, mingw32 and Ruby just typing ‘rake’.

http://blog.mmediasys.com/

I have successfully built a C extension with it. And it works.

However, I’ve asked myself that same question. Trouble would be to
define the Ruby environment for building extensions for things like
GTK+/GNOME2, which are available pre-compiled at the moment (storage of
header-files, how mkmf works, what needs to be handled, etc. In short, I
don’t know the scope of this tangled mess just yet, and can’t start
unraveling the threads).

The up-shoot is, that I was able to install the tmail extension with
Luis’ installer recipe

ahm, you already did.

If anybody has an idea how to tackle the problem of redistributing
extensions, I’d be grateful as heck.

Well, Luis L.'s work is promising. It’s time for extension
developers to try this environment and make the changes needed. After
that, anybody would be able to automatically download and build
extensions.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerardo S. Gómez Garrido wrote:

| Well, Luis L.'s work is promising. It’s time for extension
| developers to try this environment and make the changes needed. After
| that, anybody would be able to automatically download and build
| extensions.

It indeed is. However, the best solution would be to offer an SDKish
package for developers, and a RREish (Ruby Runtime Environment :P) at
the same time. The former for developers, and the latter for end-users.

However, this distinction is a bit blurry, with Ruby not compiling to
byte-code/machine code, and not needing a compiler environment as Java
does.

However, I’m of the opinion that nobody who doesn’t want to, shouldn’t
have to compile extensions.

And to handle these case, it is necessary to define a way to handle
header files and source files on the one hand, and to handle “just” the
extensions in a neat way (integrated to RubyGems would be best.
Something like a #has_gcc_compiler? method.

shrugs


Phillip G.
Twitter: twitter.com/cynicalryan

At the source of every error which is blamed on the computer you will
find at
least two human errors, including the error of blaming it on the
computer.
~ – Tom Gibb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf6L/8ACgkQbtAgaoJTgL88PQCfSqTE8HuN5Ir1Rf0j24O2YDGn
ypEAoKTSf1BWphH3mAMj51UbiEqE2ER2
=YUgW
-----END PGP SIGNATURE-----

On 7 abr, 11:30, Phillip G. [email protected] wrote:

It indeed is. However, the best solution would be to offer an SDKish
package for developers, and a RREish (Ruby Runtime Environment :P) at
the same time. The former for developers, and the latter for end-users.

Hey Phillip,

Thank you for testing and advertising the progress of One-Click
Installer with MinGW.

For the record, there is a plan for two packages: A Runtime
Environment (Ruby+RubyGems) and a Developer Kit (MinGW+MSYS), as
described in my blog:

http://blog.mmediasys.com/2008/03/29/progress-of-one-click-installer-rubyinstaller/

The idea is those gems that didn’t come pre-built for i386-mingw32
platform, you can install the Developer Kit and get it build, without
messing with manually getting MinGW and MSYS installed.

However, this distinction is a bit blurry, with Ruby not compiling to
byte-code/machine code, and not needing a compiler environment as Java does.

However, I’m of the opinion that nobody who doesn’t want to, shouldn’t
have to compile extensions.

Well, is not easy for gem developers provides pre-built binaries for
their work across every platform ruby is available. Sometimes they
need our help :wink:

And to handle these case, it is necessary to define a way to handle
header files and source files on the one hand, and to handle “just” the
extensions in a neat way (integrated to RubyGems would be best.
Something like a #has_gcc_compiler? method.

I had discussed this several times with lots of folks, is not RubyGems
responsability handle your compiler needs, currently it fires the make/
nmake procedure after called extconf script.

Also, you can provide optionals to extconf (mkmf) with --path-to-this-
library, which will keep your MinGW environment clean. That is a good
practice on other platforms, should be the same for Windows.

shrugs

:wink:

Regards,

On 4/7/08, Luis L. [email protected] wrote:

It indeed is. However, the best solution would be to offer an SDKish
package for developers, and a RREish (Ruby Runtime Environment :P) at
the same time. The former for developers, and the latter for end-users.

Hey Phillip,

Thank you for testing and advertising the progress of One-Click
Installer with MinGW.

Hey Luis. Actually, that was me :wink:

For the record, there is a plan for two packages: A Runtime
Environment (Ruby+RubyGems) and a Developer Kit (MinGW+MSYS), as
described in my blog:

http://blog.mmediasys.com/2008/03/29/progress-of-one-click-installer-rubyinstaller/

The idea is those gems that didn’t come pre-built for i386-mingw32
platform, you can install the Developer Kit and get it build, without
messing with manually getting MinGW and MSYS installed.

That sounds great.

By the way, in case the e-mail I sent you got lost, Ruby/Informix
already compiles and works on OCI/mingw32 without modifications
(except for some modifications in extconf.rb). From the same source I
can build gems and binary gems for any platform, OCI/VS6 and
OCI/mingw32 included.

About packaging gems with C extensions, either for Unix/Linux or
Windows, I fail to see what’s the big deal or why would anyone need a
generator script. I would rather support Phillip’s effort to write
decent documentation or follow examples from the projects that already
do it than giving recipies to newbies that would slow them down in
their learning process.

On 7 abr, 11:08, Phillip G. [email protected] wrote:

And to put my money where my mouth is, I’ll write up a bare-bones
tutorial on how to build a gem, and send it off to the Rake folks (I’m
using Rake to generate my gems and packaging, so cut me some slack,
will you. :P)

You should take a look at what Dr.Nic Williams did:

http://drnicwilliams.com/2008/04/01/writing-c-extensions-in-rubygems/

|
| Why not compile natively on Windows?

Setting up a MinGW/MSYS environment is a bit of a hassle, especially if
you want GCC 4, since the MinGW32 folks lag behind on that.

Well, try adapting my recipes and use the TDM GCC4 releases instead,
just keep the MSYS files there:

Oh, please use GCC4 with SJLJ, since dw2 sometimes segfaults with
Ruby :wink:

However, I’ve asked myself that same question. Trouble would be to
define the Ruby environment for building extensions for things like
GTK+/GNOME2, which are available pre-compiled at the moment (storage of
header-files, how mkmf works, what needs to be handled, etc. In short, I
don’t know the scope of this tangled mess just yet, and can’t start
unraveling the threads).

I’ve been informed about extensions/gems that already build with this
‘sandboxed MinGW’:

wxRuby
Ruby-GNOME
RMagick 2

So I think getting other projects working is not painful as someone
can think of (at least for me).

The up-shoot is, that I was able to install the tmail extension with
Luis’ installer recipe (and tmail compiled itself happily. I have no
idea if it works, though :P), which makes me wonder if it isn’t possible
to distribute a Ruby version which comes with a compiler environment for
developers, with an option to build a Ruby redistributable (sort of like
the Visual C runtime, or a Java VM) for deployment, and/or have a Ruby
distribution for end-users only, who want to run pre-defined scripts,
they get handed by somebody (An analogue of the Java world: A Ruby SDK
ala the JDK for developers, and a Ruby RE ala the JRE for end users).

Wow, already replied this :slight_smile:

In principle this is possible, as Rubyscript2exe, and exerb demonstrate.

RubyScript2Exe and exerb are kind of “hacks”, until there is a
mechanism to ship the VM and the required dependencies as “packages”,
like Rubinius is doing with .rba files or Python do with the custom VM
and zip files, we will be stuck on this.

There is no mechanism in the Ruby VM to do something like that right
now.

If anybody has an idea how to tackle the problem of redistributing
extensions, I’d be grateful as heck.

Wrap your extension as a gem, use tools like newgem, Hoe or Echoe and
ship precompiled binaries sticking Gem::Platform::CURRENT in your
Gem::Specification

Regards,

On Apr 7, 2008, at 06:33 AM, Gerardo S. Gómez Garrido wrote:

| http://docs.rubygems.org/read/chapter/20#platform
I have checked the page again, it was generated in 2005. This is
unacceptable. Being gratis or open source is not an excuse.

I’m sorry that I chose to devote my free time to something other than
updating an old page with proper documentation, but thank you for
volunteering to update the documentation for me.

I believe Jim W. currently is hosting and originally generated
this documentation, so you’ll need to contact him to regenerate or
replace it with correct documentation.

However, I think the best place to document gem build is at gem help build which will save you lots of time, as I can quickly check
in a documentation patch. The file you want to look at is lib/
rubygems/commands/build_command.rb. You can find the repository on
the RubyGems project at RubyForge.