gmane.os.apple.homebrew.devel

Re: Node NPM - no formula available

bidnez account — 2013-06-06T21:53:34

hello, geoff, et al,

i was having similar issues yesterday and mistym in the #machomebrew channel of freenode.net irc helped me with this.

that is an older package of node.js with npm separated out of the homebrew formula, like node.js vers. 0.8.0.

the current stable version homebrew has a package for is node.js vers. 0.10.10, with npm included, so you no longer need the separate curl script for it (also why that curl script no longer works).

do —

$ brew update

and once that completes successfully (you might have some files and dependencies to add or move around, as i did, to get update to complete), then run —

$ brew install node

... which should install the latest node.js 0.10.10 and it's correct npm. you can verify after install by doing —

$ node -v

$ npm -v

that worked for me. hope this helps you.

—  faddah wolf
     portland, oregon

Sent from my slick, cool, white iPad 2012... 'cuz i am so '7337!!


On Jun 6, 2013, at 2:24 PM, Geoff Hoffman <ghoffman-tFexAHto8dV2j+Rk3+F/YA< at >public.g

Node NPM - no formula available

Geoff Hoffman — 2013-06-06T21:24:45

Mac-mini:~ me$ brew install npm
Error: No available formula for npm
Mac-mini:~ me$ brew install node npm
Error: No available formula for npm
Mac-mini:~ me$ curl http://npmjs.org/install.sh | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time
 Current
                                 Dload  Upload   Total   Spent    Left
 Speed
100    85    0    85    0     0    335      0 --:--:-- --:--:-- --:--:--
867
sh: line 1: syntax error near unexpected token `newline'
sh: line 1: `<html>Moved: <a href="https://npmjs.org/install.sh">
https://npmjs.org/install.sh</a>'

Thanks to this stackoverflow post
http://stackoverflow.com/a/12751548

I realized that the reason is because npm is now bundled with node, so the
standalone npm install just fails with cryptic messages.

Hope it helps someone.

Re: recording CPPFLAGS used during build

Peter Eisentraut — 2013-06-03T20:20:58

Yes, that works.  Thanks.

Re: recording CPPFLAGS used during build

Justin Clift — 2013-05-31T09:06:12

Does "env :std" do what you're looking for?

As an existing example, the mariadb.rb formula and some other ones
(non-database) use it.

Regards and best wishes,

Justin Clift

--
Open Source and Standards < at > Red Hat

twitter.com/realjustinclift

recording CPPFLAGS used during build

Peter Eisentraut — 2013-05-30T19:16:16

This is related to this issue:

https://github.com/petere/homebrew-postgresql/issues/2

I have a tap that builds PostgreSQL with gettext/libintl.  (The standard
formula doesn't do that, but it reasonably could.)  When one builds a
PostgreSQL plugin (which is what the reporter of the above bug did),
that ends up wanting to include libintl.h, because that's what the
header files supplied by PostgreSQL do.  Since gettext is keg-only,
libintl.h is not in the default path.  In a Homebrew build environment,
building PostgreSQL this way works, because the include directories of
all keg-only formulas are automatically added to the build flags
(correct?).  But this is not recorded anywhere, so the plugins I'm later
building have no idea how the Homebrew PostgreSQL build got its header
files.

This issue potentially exists for all packages that have keg-only build
dependencies and exposes its header files for building plugins.  Maybe
there aren't that many of those.

What I'd ideally like is a way to write some varian

Re: More advanced testing

Adam Vandenberg — 2013-05-28T00:26:21

These aren't directly supported right now, but with brew-build-bot getting
developed and the test hardware coming online, we definitely have momentum
to improve the situation.


On Mon, May 27, 2013 at 2:17 PM, David Hall <dhcrawley-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

More advanced testing

David Hall — 2013-05-27T21:17:31

I have a couple of more advanced testing ideas, and I was wondering if these are already possible within the current homebrew release? There is not much documentation on providing tests for formulae.

1. Is it possible to perform different tests based upon the installation configuration? For example, if you have an optional dependency, it might be nice to test that the linking worked correctly. But you would only want to perform this test if this option was enabled.

2. Is it possible to provide nicer output? For example, print a string based on the return value of the test. I imagine this is possible within ruby, but I was wondering if there is something within homebrew to handle this explicitly?

Thanks,
David

Re: Separating source and binary trees during build

David Hall — 2013-05-27T18:46:54

Thank you both for your help. For the archives, my final solution was:

def install
    mkdir '../build' do
      system "cmake", buildpath, "-Dmomentum:STRING=GEV", "-Dlength:STRING=MM", *std_cmake_args
      system "make install"
    end
  end

Cheers,
David


On 27 May 2013, at 16:57, Jack Nagel <jacknagel-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: What would it take to do a superenv for Snow Leopard?

Misty De Meo — 2013-05-27T17:57:17

Pushed a commit that improves compiler selection (but doesn't turn
superenv on for Xcode 3.2.6 yet).

https://github.com/mxcl/homebrew/commit/08523d915856d75e9de02085c9498fc848e4bbc4

On Mon, May 27, 2013 at 12:50 PM, Misty De Meo <mistydemeo-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: What would it take to do a superenv for Snow Leopard?

Misty De Meo — 2013-05-27T17:50:07

It also benefits us by exposing unexpected issues in the code. I find
weird older environments really useful for stress-testing this kind of
thing. I've already run into some bad assumptions and edge cases
within the scope of those small changes that theoretically *could*
affect newer Xcodes at some point.

On Mon, May 27, 2013 at 12:37 PM, Adam Vandenberg <flangy-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: What would it take to do a superenv for Snow Leopard?

Adam Vandenberg — 2013-05-27T17:37:33

Though I suppose it will encourage tagging older `fails_with` versions.


On Mon, May 27, 2013 at 10:28 AM, Adam Vandenberg <flangy-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: What would it take to do a superenv for Snow Leopard?

Misty De Meo — 2013-05-27T17:30:37

OK, so I gave this a try today. I had 64 outdated packages, so it ran
across a good cross-section of stuff (both C and C++).

The results are actually really promising. After I made changes to
about ~14 LOC (in `determine_cc` and `tool`) everything is working
smoothly; the only software that won't build won't build in stdenv
either.

On Mon, May 27, 2013 at 4:19 AM, Mike McQuaid <mike-NL2XmxyG56w7/pHV7SlfWg< at >public.gmane.org> wrote:

Re: What would it take to do a superenv for Snow Leopard?

Adam Vandenberg — 2013-05-27T17:28:00

Symlinking 3.2 -> 4.3 let Tig compile, but it is choosing `clang` by
default apparently. Probably not what we want for 3.2.

determine_cc will need to be updated I suppose.


On Mon, May 27, 2013 at 2:19 AM, Mike McQuaid <mike-NL2XmxyG56w7/pHV7SlfWg< at >public.gmane.org> wrote:

Re: Separating source and binary trees during build

Mike McQuaid — 2013-05-27T16:14:51

On 27 May 2013, at 16:23, David Hall <dhcrawley-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:



`system "cmake", srcDir` is equivalent so use that.

Mike McQuaid
http://mikemcquaid.com

Re: Separating source and binary trees during build

Jack Nagel — 2013-05-27T15:57:59


Just change

"#{srcDir}"

to

srcDir

(the string interpolation is unnecessary).

Though you can actually just use the buildpath attribute, which is
always set to the build root.

Jack

Separating source and binary trees during build

David Hall — 2013-05-27T15:23:39

I'm developing a formula which requires the binary tree to be outside the source tree during the build. This is enforced by the CMakeLists file of the package.

I currently achieve this by:
def install
   # Build directory must be outside source directory tree
   srcDir = Dir.pwd
   mkdir '../build' do
     system "cmake", "#{srcDir}", "-Dmomentum:STRING=GEV", "-Dlength:STRING=MM", *std_cmake_args
     system "make"
     system "make install"
   end
 end

but this causes brew audit to complain
"Don't need to interpolate "srcDir" with system"

Any suggestions?

Re: What would it take to do a superenv for Snow Leopard?

Mike McQuaid — 2013-05-27T09:19:20

On 26 May 2013, at 23:42, Misty De Meo <mistydemeo-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


Sounds to me like it might be worth just turning on (assuming it doesn't crash and burn). Longer-term I think it would be good to kill stdenv by adding enough stuff to superenv that it's no longer needed (for core formulae at least). When doing stuff like fixing the bottle CFLAGS it's pretty annoying to have to fix the same problem across two very different code paths.

Mike McQuaid
http://mikemcquaid.com

Re: What would it take to do a superenv for Snow Leopard?

Misty De Meo — 2013-05-26T22:42:27

I'll give it a try tomorrow and see what crashes and burns.

I've been interested in adapting superenv for Xcode 3/2.5, so I'm
hopeful there isn't too much that needs adjustment.

On Sun, May 26, 2013 at 5:34 PM, Jack Nagel <jacknagel-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: What would it take to do a superenv for Snow Leopard?

Jack Nagel — 2013-05-26T22:34:08

A starting point would be symlinking Library/ENV/3.2.6 to
Library/ENV/4.3 and see what doesn't work.

Since I have Xcode 4.2 installed on 10.6 I have a 4.2 -> 4.3 symlink
and pretty much everything just works, though I'm guessing that's not
the case with 3.2.6.

On Sun, May 26, 2013 at 3:30 PM, Adam Vandenberg <flangy-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

What would it take to do a superenv for Snow Leopard?

Adam Vandenberg — 2013-05-26T20:30:54

Not that there's much benefit to this at this point, but what would it take
in general to create a superenv profile for Snow Leopard?

Re: Taps vs. Formula directory

Mike McQuaid — 2013-05-24T10:41:32

On 21 May 2013, at 04:09, Tim Moore <tmoore-RpA6I7J3ewCKqjuihJC/7axOck334EZe< at >public.gmane.org> wrote:


Agreed, nice work Charlie.


There isn't one really. Probably depends on one of us having a good chunk of time to get started on it.


We do. However we only give commit access to people who have had consistently good pull requests and been consistently helpful on the issue tracker for a while. Even fixing an odd issue here and there would be incredibly helpful to the project though and we'd love it if you could help.

Mike McQuaid
http://mikemcquaid.com