in lang/ruby/1.*/Makefile.
Also, add the ability to pass CONFIGURE_ARGS to gem install.
These get passed to the extconf.rb scripts that create the
Makefiles for C extensions, and may make it easier to port
gems with C extensions without resorting to patching.
OK landry@
depend on ruby-1.9 and not ruby-1.8. This PKGSPEC is slightly
different from the previous one used in ruby.port.mk, so all
dependent ports need to be REVISION bumped (which will happen soon).
In addition, since the subpackages depend on the -main package and
also had a slightly different pkgspec, they need to be bumped as well.
In addition, the -main package is also being bumped for the inclusion
of a patch for Addrinfo that fixes a failing IPv6 UDP regression test.
OK landry@
depend on ruby-1.8 and not ruby-1.9. This PKGSPEC is slightly
different from the previous one used in ruby.port.mk, so all
dependent ports need to be REVISION bumped (which will happen soon).
In addition, since the subpackages depend on the -main package and
also had a slightly different pkgspec, they need to be bumped as well.
OK landry@
The Rubinius bytecode virtual machine is written in C++, incorporating
LLVM to compile bytecode to machine code at runtime. The bytecode
compiler and vast majority of the core classes are written in pure Ruby.
To interact with the rest of the system, the VM provides primitives
which can be attached to methods and invoked. Additionally, FFI provides
a direct call path to most C functions.
Rubinius uses a precise, compacting, generational garbage collector. It
includes a compatible C-API for C extensions written for the standard
Ruby interpreter (often referred to as MRI.Matz's Ruby Implementation).
OK landry@, sthen@
* No longer remove ruby-* from PKGNAME when building FULLPKGNAME for
the gem and extconf ports
* Correctly remove ruby18 FLAVOR
* Use extract/build/install cookies
* Fix installing of certain gems as root without systrace, by working
around a bug in devel/ruby-gems
* Remove MODRUBY_REV from SUBST_VARS
OK landry@
ruby 1.8, ruby 1.9, and jruby.
One major change for all ports is that RDoc documentation is no longer
going to be installed by default for gem ports. For ruby 1.8, it used
a separate documentation file per method, and the file names created
weren't consistent across ruby versions (1.8.6 differed from 1.8.7,
and 1.8.7 differs from 1.9.2 and jruby). It made reviewing diffs very
painful, and since most ruby developers do not use the documentation
(preferring web documentation), it doesn't make sense to include them.
For most gem ports, a ruby 1.9 version can be built by using
the ruby19 FLAVOR, and a jruby version can be build using the jruby
FLAVOR. These flavors modify the FULLPKGNAME to use either the
ruby19- or jruby- package stem, so you don't need to worry about
the ruby 1.8 package conflicting.
In most cases, you no longer need the PKGNAME set in the port
Makefile, as the FULLPKGNAME handling will take care of that for you.
Also, for pure ruby gems (without C extensions), PKG_ARCH = * is added
automatically.
Changes to all dependent ports will be committed shortly. For new
ruby ports, you need to make sure that gem dependencies are specified
like this (assuming they depend on the hoe gem):
:${MODRUBY_PKG_PREFIX}-hoe-*:devel/ruby-hoe,${FLAVOR}
MODRUBY_PKG_PREFIX will be ruby for ruby 1.8 ports, ruby19 for ruby
1.9 ports, and jruby for jruby ports. The ,${FLAVOR} part at the end
makes sure that dependencies use the same version of ruby that
the current port uses.
PLISTs are going to become a lot smaller with this. However, any
binaries installed by the gem need to have a special string added.
For example, the minitar binary installed by
archivers/ruby-archive-tar-minitar looks like this in the PLIST:
${GEM_BIN}/minitar${GEM_BIN_SUFFIX}
The ${GEM_BIN_SUFFIX} needs to be added manually so the package
works on ruby 1.9, which installs the binaries with a 19 suffix.
GEM_SKIPDEPENDS has been removed and related support will be removed
from devel/ruby-gems. To modify dependencies inside the gem, the gem
metadata is placed under WRKDIST and can be modified with the standard
patching procedure.
OK landry@
hs-glib (and probably other stuff that uses the Cabal library).
Bump both -main and -doc (yes, really, -doc, too).
I hereby nominate myself for the HSMAUS (Homer Simpson Memorial
Award of Unlimited Stupidity).
libraries not coming together with ghc. This allows for looking up
a library's PKGPATH by running
ghc-pkg field $pkgname pkgpath
where $pkgname is the GHC library name without the `hs-' prefix,
for example `ghc-paths'.
looks good to jasper@
cabal and without nort), to avoid collisions with other (non-Haskell)
ports;
- Documentation is installed as ${PREFIX}/share/doc/hs-$foo instead of
${PREFIX}/share/doc/$foo.
- The library itself (and its interface files) is installed as
${PREFIX}/lib/ghc/$foo instead of ${PREFIX}/lib/$foo.
- Additional files will be installed in ${PREFIX}/share/hs-$foo instead
of ${PREFIX}/share/foo.
from kili@
depending port's plists will be adjusted in a few
performance increases and ruby 1.8.7 support. ffi support now works in
simple cases. It now works on amd64 as well. I'm taking over
maintenance from bernd@.
ok landry
Also, if CONFIGURE_STYLE includes ext or extconf, update WANTLIB
and LIB_DEPENDS, and set SHARED_ONLY=Yes. That configure style
is only used for ruby C extensions, which need those settings.
This cleans up a lot of ruby C extension ports, which will be
committed shortly.
ok landry, phessler, sthen
automatically change from scripts from using /usr/bin/env python or
/usr/bin/python to using #!${MODPY_BIN} .
Add a MODPY_ADJ_FILES in which you can put the files that are under
${WRKSRC} you want to subtitute the shebang.
e.g.
MODPY_ADJ_FILES= setup.py bin/foobar.py.in
Some input from djm@
"sane idea to me" jasper, ok sthen@
build them during the build stage and install them during fake.
devel/ruby-gems doesn't have separate build and install commands, as
most gems are pure ruby code and don't need a separate build stage.
When ruby-gems is installing a gem with C extensions, it builds them
during the install. Since installing is done during the fake stage,
this meant that the extensions were getting built as root.
Previously, this was required, as gem's --user-install option was
broken. However, since that option has now been fixed, we use
it to install the gem to a temporary location as the current
user during build, and then mv and chown the files during fake.
Thanks to bernd@ for pointing out that the fixed --user-install
option allowed this.
ok landry
attempting to create all intermediate directories and rescuing failures,
don't attempt to create directories that already exist. Fixes systrace
warnings when building ruby ports.
ok landry
meant to be used on archs that have gcc4 in base, this doesn't require a
full gcc build from ports, and provides libgfortran as a subpackage.
idea from espie some months ago.
perl command that accepts filename arguments and modifies the common
/usr/bin/env ruby shebang to ${RUBY}. MODRUBY_ADJ_FILES is a short
cut that allows you to set filename patterns and have
MODRUBY_RUBY_ADJ called on all files in ${WRKSRC} that match that
pattern. It adds a pre-configure action to do so, if a pre-configure
action is not already defined. If a pre-configure action is already
defined, you can call the replacement command with
${MODRUBY_ADJ_REPLACE}.
ok sthen, landry
for gems with native extensions. Without this, it calls
/usr/bin/install -o root -g bin as a regular user, which fails due
to permission issues. This removes the -o root -g bin, so it can
succeed as a regular user.
This same patch was recently added to devel/ruby-gems, which is
specific to ruby 1.8. ruby 1.9 ships with ruby-gems, so the
patch needs to be included here as well.
OK landry@
All ruby .gem files are now hosted on rubygems.org in the same
directory. If the ruby gem CONFIGURE_STYLE is used, make the
default MASTER_SITES that directory.
There are still a few uses of MASTER_SITE_RUBYFORGE in the tree, for
some ports that aren't gems, or where the .gem file isn't hosted on
rubygems.org, or where the hashes don't match. Most of these will be
dealt with in the near future.
OK landry@
Haskell-Source with Extensions (HSE, haskell-src-exts) is an extension
of the standard haskell-src package, and handles most registered
syntactic extensions to Haskell, including:
* Multi-parameter type classes with functional dependencies
* Indexed type families (including associated types)
* Empty data declarations
* GADTs
* Implicit parameters
* Template Haskell
[..]
feedback/ok kili@
1.9, similar to how the lang/python ports are handled. ruby 1.8
now installs as ruby18 and ruby 1.9 installs as ruby19. The
included MESSAGE files for both ports let you know the symlinks to
set up if you want to make that version the default system ruby.
Split port originally started by bernd@, many changes since by me,
help and support from jcs@, landry@, jasper@, and sthen@.
This causes a large amount of fallout in dependent ruby ports,
which will be committed shortly.
OK jcs@, landry@, jasper@, sthen@
built with python versions previous to 2.6.
- Simplify MODPY_BADEGGS.
- Fake setuptools if MODPY_SETUPTOOLS is not present to detect those ports
that will build regardless but the resulting plist will be different.
Input, tested and ok by many, thanks!
the stm package), which is no longer possible, because TMVar is deriving
Eq now. So move the (somewhat crude) comparision based on addressOf (which
comes from the hs-pugs-compat package) into Pugs.AST.Types, providing an
explicit Eq instance for VThread.
IMHO, instance declarations for standard type classes on types imported
from other Haskell packages are evil.
Breakage noticed by naddy@.
While here, update WANTLIB and bump.
MULTI_PACKAGES, and add an (ONLY|NOT)_FOR_ARCHS-subpkg=somearch, rather
than changing contents of the MULTI_PACKAGES variable.
Fixes dpb builds on !amd64/i386, because the bsddb package was
knocked out on other arch.
'please unfuck the fucking mess people only testing on i386 and
amd64 did' landry@
libc. While here, switch to new REVISION/WANTLIB scheme.
Problem noticed by ajacoutot@
ok espie@ sthen@
Please note that any Haskell library depending on ghc-6.12.3
(cabal-wise) needs to be rebuilt. This affects devel/haddock
and devel/hs-QuickCheck, which will be bumped in a minute, but
if you've some libraries not contained in the ports tree, be
sure to double-check with ghc-pkg check.
Haskell language isn't the same as more than a decade ago.
Suggested by Daniel Dickman, and since the other ports guys
are only joking around, I think nobody will miss it.
While here, also remove xmms.
(just kidding)
not convertible to 1.9, etc etc. While here remove MAINTAINER per his
request, update licence marker, fix depends and use REVISION.
No cries of despair on ports@
Icarus Verilog is a Verilog simulation and synthesis tool. It operates
as a compiler, compiling source code writen in Verilog (IEEE-1364) into
some target format. For batch simulation, the compiler can generate C++
code that is compiled and linked with a run time library (called "vvm")
then executed as a command to run the simulation. For synthesis, the
compiler generates netlists in the desired format.
there are no core and extensions packages anymore, everything is built by
the main ports itself and the package names have changed to php-${V} or
php-mysql-${V} for modules.
The new ports allows you to install all of the php versions just like python
so you can actually run different webservers with different versions of php
because you can't load two modules to one. You can only do that with fastcgi.
The port tries to share all the files that can be shared and the different
extensions are located in the local version's Makefile instead of Makefile.inc.
The other change is that *all* of the configuration has moved to /etc out
of /var/www because that was a realy stupid concept, since apache if you
use it chrooted, will load all of the extensions before doing the actual
chroot.
This port is not linked to the build yet because several issues have to
be resolved first, like providing a way to update from php5-* packages,
and probably other things that do not come into my mind right now,
because the Bullfrog is making me crazy.
I fetched my distfile from the old place, before switching
MASTER_SITES to the new one (darcs.haskell.org). Same content,
but different size and checksums (because the files have been
created on different dates).
- Use integer-gmp again.
- Cleanout the extracted bootstrap directory right after installing it
to save some disk space.
- Use ${MAKE_ENV} instead ${MODGHC_SETUP_CONF_ENV} in ghc.port.mk (in
do-configure, use both).
- Don't compile Setup.l?hs, just use the interpreter (runghc) in
ghc.port.mk. This speeds up the build of most ports depending on
ghc and using a cabal-style build.
Necessary bumps and WANTLIB changes in ports using ghc will follow
later this evening.
Since the new bootstrapper has a new name (ghc-6.12.2.20100530),
the ABI of some libraries included in GHC will change, possibly
breaking all other libraries, so expect some additional bumps soon.
Yes, this *is* ridiculous. If you want to live in peace, don't use
GHC.
paraemters to ghc-pkg. Remove the (now obsolete) patch for Register.hs.
Ports that build ghc libraries should now use the following
@exec/@unexec magic (('ve already diffs for all the hs-* ports in
my tree):
lib/${DISTNAME}/register.sh
@exec /usr/bin/env HOME=/nonexistent %D/lib/${DISTNAME}/register.sh -v0
@unexec /usr/bin/env HOME=/nonexistent %D/lib/${DISTNAME}/unregister.sh -v0 --force
lib/${DISTNAME}/unregister.sh
for unregister.sh in all the new ghc libraries (which leads to bogus
registered ghc packages after updates).
You can use the command
ghc-pkg check
to check ghcs internal package list. If it reports missing files
for some package (like hashed-storage-0.4.11), you can forcibly
unregister it by running (as root) something like
ghc-pkg unregister hashed-storage-0.4.11
ok dcoppa@
- obstack.h uses casts as lvalues, fix those
- hack standard includes to avoid tons of strlen/malloc warnings (may
even fix bootstrap on other things than i386)
- remove non-standard assert.h that requires an eprintf in libgcc.
- bump pkgname, just in case...
verified to work with both gcc3 and gcc4.
just setting MODGHC_SETUP_CONF_ARGS (which is now empty by default).
Add dblatex-created documentation.
While here, use our INSTALL* macros where possible to get correct
permissions (noticed by dcoppa@). This does *not* fix the permissions
of libraries and interface files installed by Cabal-based tools,
because the permissions are hard-coded in Cabal, and I'm not going
to touch and fix Cabal ever, because IMHO it's completely broken
by design. (If you want to read some of this madness, have a look
at libraries/Cabal/Distribution/Compat/CopyFile.hs or even
libraries/Cabal/Distribution/Simple/Install.hs)
Expect some breakage of depending ports (at least of devel/darcs) and
some necessary WANTLIB changes, which will be fixed soonish.
the APIs of GHCs libraries depend on the version of the bootstrapping
compiler (and probably on the output of pom(6) and the amount of
active vulcanos in iceland).
See http://hackage.haskell.org/trac/ghc/ticket/4012#comment:3 for
details.
THIS ALSO MEANS THAT IF YOUR BUILD FAILS, YOU WILL HAVE TO MAKE
CLEAN AND START FROM SCRATCH! NEVER EVER TRY TO RESTART THE BUILD
OR THE LIBRARY ABIS WILL CHANGE! (Sorry for yelling)
Bump PKGNAME-main, since people may already have built ghc with
native_bootstrap.
Many thanks to Darrin Chandler and dcoppa@ for testing, reporting about
broken stuff, missing dependencies here and in ports depending on ghc.
Notes and rants:
- Bootstrapping is done using precompiled binaries, since .hc
bootstrapping still doesn't work. I really hate this.
THIS MEANS THAT GHC IS NOW AND WILL STAY LEGACY-ONLY (i386 and amd64)
At least until someone fixes it. I tried for more than two year
(well, only in my spare time and during my vacations) and failed.
- libgmp is currently disabled, because I didn't yet hack the GHC build
system to use the system libgmp instead of the patched one included
in GHC.
- The haddock ncluded in the ghc distfile is replaced by the version
of haddock found in devel/haddock. Haddock itself is @commented
in the ghc PLIST. Unfortunately, this needs an ugly hack that
introduces an otherwise useless pseudo flavor `no_deps' in
devel/haddock.
- CLDouble has been removed from GHC some time ago, because it was
an alias for double (AFAIK there's now support for long double
in GHC). As this isn't a really big problem, it currently breaks
c2hs, which I'll mark broken temporarily before committing the
ghc update.
- The external codeset defaults to latin1 (suggested by Simon Marlow)
and can be overridden by setting the HS_ENCODING to any codeset
supported by libiconv.
- ghc.port.mk still needs some love, especially for letting a port add
additional parameters to certain invocations of ${MODGHC_SETUP_PROG}.
get process informations. Remove the mkbundle.cs patch and replace it
with one that uses configure.in so the libgc dependency ends up in the
pkg-config file. Move disabled features to configure.in from our Makefile
