I've tried to get postgresql 8.4 via MacPorts (on Snow Leopard) but it seems that the dependencies are endless - including getting older version of stuff that is already available in Snow Leopard, kitchen-sink and who knows if eventually I end up with windows 7 ...
Is there a way to get only those dependancies absolutely necessary to run stuff from command line in Mac?
Especially I'm trying to avoid installing old version of python, Xorg packages and so on.
Any ideas? So far it seems that it is better to avoid MacPorts altogether.
Looking at the port file for postgresql84, the +python variant for it actually means python2.5. Most of the dependencies you find annoying are probably being brought in by the python tkinter module dependency on Tk which by default builds an X11 version of Tk rather than the +quartz variant. You can change that by specifying that variant and reinstalling. The easy way to deal with variants is to add the options you normally want to use as defaults to those in /opt/local/etc/macports/variants.conf.
Unfortunately, at the moment, the tk +quartz variant build is broken on Snow Leopard. So, if you are not planning to use tkinter (or IDLE) with the MacPorts python2.5, you can force the removal after the fact of the unwanted modules:
port installed
port -f uninstall tk Xft2 xorg-libX11 ...
You might want to first do a dry-run by adding the -y option to see exactly what the effects of the uninstall will be.
Note, the python26 port has a handy +no_tkinter variant which could be useful once the portgresql ports are upgraded to python2.6.
It's potentially a bit of grunt work (and definitely violates Occam's razor for this particular scenario)... but if you're positive you know which dependencies you don't want/need, they can always be passed as hyphen-delimited args after the port call:
port install sweetPort -depYouDontWant -depYouDontNeed ...
I know it's been a while since the OP, but I hope this helps... somebody.
Related
Background
Working with OS X and using macports for additional utilities and libraries. The macports are installing everything into /opt/local. But the default perl in macports is 5.12, specifying an higher version like to break many ports, so I'm using my own 5.16 perl installed with perlbrew.
So, I have libraries in the default /usr/lib (provided by Apple) but want linking XS based perl modules with the macports provided libs and includes at /opt/local.
Now the question, when installing modules with cpanm (into my perlbrew's perl tree), is here some way how to specify globally the default search path for libraries and includes for cpanm (to the modules build process) to search /opt/local/{lib|include} at first?
AFAIK the cpanm havent any switches for this, so maybe, some ENV variables? Or any simpler solution as edit every Makefile.PL?
Install half manually. Run cpanm --look Some::Dist and supply the appropriate INC and LIBS or --include_dirs and --extra_compiler_flags to the build tool on the command line to configure, then finish off with the build, test, install steps and close the subshell.
Alternatively, if you need to fully automate this, then use a full-featured CPAN client instead of cpanm. For example, run the cpan shell and configure makepl_arg and mbuildpl_arg. This is then supplied to subsequent installations (instead of just one, as above).
i'm having loads of problem in trying to install CPAN Modules. Using the cpan.exe, I try to install a module with, for example, "install Win32::IE::Mecahnize" but I end up hitting a wall. In the beginning it find dmake.EXE and is okay, but when the install finishes it says dmake.exe is NOT OK, and Dmake.exe Error code 255 , while making 'test-dynamic'.
I'm very confused as to what is happening and why its not working?? Help is much appreciated.
This is the current error I get:
dmake.EXE: Error code 255, while making 'test_dynamic'
C:\strawberry\c\bin\dmake.EXE test -- NOT OK
Running make install
make test had returned bad status, won't install without force
ABELTJE/Win32-IE-Mechanize-0.009.tar.gz : make_text NO
It's not your fault. That module doesn't work for anyone. When you run into a failure with a module, investigate it to see if other people are having problems. You can look on its CPAN Search page to see that there are no passing testers reports for that distribution. That distribution should not install without force. We cover some of this in Effective Perl Programming's section on researching modules.
Can you install other modules without a problem?
ya, well here's the thing, I have both ActivePerl and Strawberry Perl installed, is that a problem?
Shouldn't be an issue. However, you need to make sure that Strawberry Perl's distro contains the binaries and libraries you need to build and install non-text only modules. You need to make sure you're using Strawberry Perl's stuff and not ActivePerl. I recommend putting Strawberry Perl in your PATH, but not ActivePerl.
Easiest thing to do is not use CPAN, but ActivePerl's own PPM manager. ActivePerl has probably prebuilt about 90% of the CPAN modules and have them available via their PPM manager. Try that.
I have to run a Rails (3.0.6) app locally that requires Ruby 1.9.2 (plus Mongo). I'd like to install Ruby 1.9.2 alongside my existing 1.8.7 and be able to swap between them as necessary. I prefer installing to usr/local over Macports etc. Any recommendations? I've tried installing RVM but this has proved such a pain on OS X I'd rather avoid that too.
Is there another way of running multiple Ruby versions (maybe with a prefix like this)? I only need to switch to 1.9 for this project. Or has anyone a good solution to the known OS X/RVM install issues? Specifically, on Tiger/10.4 bash doesn't support errtrace.
Update: solved with a new RVM install script: see RVM on OS X 10.4 - possible?.
RVM really is the easiest solution, and I would highly recommend you try and work that issue out first.
The only bit of advice is to make sure you configure your PATH variable to include /usr/local/bin before everything else. In your .profile or .login (depending on your shell), you should have it towards the bottom, in case there is any other lines configuring PATH as well, and then for the Bourne shell family:
export PATH="/usr/local/bin:$PATH
or for the C shell family:
set path = (/usr/local/bin $PATH)
Running ./configure alone should make it install into /usr/local, but you can explicitly state so with
./configure --prefix=/usr/local
Install Ruby from source and it will default to /usr/local/bin. Adjust your path, the #! line, or your /usr/local/bin/ruby source.rb as necessary to switch between Apple's installation of Ruby, and the one you add.
You can force a new base directory using ./configure --prefix=/... where '...' is whatever path you want. Again, once the files are installed, you can adjust the executing Ruby with one of the above methods.
Do not attempt to remove Apple's installed Ruby. It's there for their use, not for our convenience, and Apple uses it to provide some functionality. Messing with it or removing it could break things, and you probably wouldn't notice for a while.
RE: RVM, It really is the preferred way to install a user Ruby. I have it on two Macs, and a handful of different Linux boxes and the only time I had trouble was with a secured machine behind firewalls, but I can't blame RVM for those problems when it couldn't see the internet at all. And, yes, I got it working nicely, I just had to insert the manually downloaded Ruby archives into the ~/.rvm/archives directory.
If you are having problems and want to use it, it might help to temporarily strip your startup scripts, or create a temporary user, and see what happens. Additionally, the author has been very responsive and helpful the few times I've asked him questions. Contact him at:
If you still cannot find what an answer to your question, find me 'wayneeseguin' in #rvm on irc.freenode.net:
http://webchat.freenode.net/?channels=rvm
If you download the source and compile it, it should install into /usr/local by default, or you can
./configure --prefix=/usr/local
just to be sure.
Actually, compiling and installing ruby from source is an easy way to be sure you have the latest version, especially if you use git and github:
https://github.com/ruby/ruby
It's late and I should go to bed and maybe that's why I can't figure this out. I'm on a fedora-13 machine and I just ran
yum install gambit-c
I installed it because I want to follow along in a schemed text book.
but now that it's installed, how do I start the scheme interpreter??
It looks from the RPM listing that the binaries are named gsi, gsix, and gsc, all in /usr/bin. I suspect that gsi is the interpreter.
For more details, there's also the manual entry for gsi.
BTW: I don't know about the Fedora RPM, but I found that the Ubuntu repository's Gambit-C was quite outdated (4.0-ish), with missing features like simple compilation of stand-alone executables. The most recent version is 4.6. If your RPM's version is a few decimal places behind, I'd suggest just installing from source; it's a pretty standard configure -> make -> make install sequence. Just remember the following option when running configure:
./configure --enable-single-host
This speeds things up quite a bit.
My attempts to install modperl under the default vanilla Leopard Apache 2 have failed and all I can find online are variations on this:
I would like if possible not to rely on MacPorts or Fink, though if they can be made to work with the default Apache 2 install that would probably be ok.
Macports has it (think apt-get and the likes on linux, but on OS X)
(you can see it listed here)
Haven't installed myself though....
Why not just give up and build/install your own or port versions of perl, apache2, and mod_perl2? Probably easier than fighting with it. (Worked for me.)
(as per comment)
Mmmkay! Sorry, I didn't intend that to be snarky or imply that it's not a valid question. I guess I'll delete this (if I can.) Would it be useful to edit the question to add your rational rationale for not having a separate installation?
Get the latest mod_perl and set the following var:
export ARCHFLAGS="-arch x86_64"
Compile/install as usual.
Taken from this post, "Building mod_perl2 on Leopard" which also links to further details on how to get Apache2::Request (libapreq) working as well.
-
(Not that I've been able to test it since I'm personally back on Tiger running Apache 1.3!)
(And let's see if stackoverflow manages to lift this answer to the top since it is the only "correct" answer)
I asked a very similar question a few days ago and got some good answers:
"How do I use a vendor Apache with a self-compiled Perl and mod_perl?"
The mc ports install of mod_perl tries to install apache 1.3 even if you specify just the mod perl, so thats not a good option.
Try this:
http://www.unibia.com/unibianet/node/32