This repository has been archived by the owner. It is now read-only.

Add `depends_on :clt` #14384

Closed
mxcl opened this Issue Aug 22, 2012 · 23 comments

Comments

Projects
None yet
5 participants
@mxcl
Member

mxcl commented Aug 22, 2012

A number of formula fail to build without the CLT installed, and my attempts to fix them prove that it may not be possible. Here is a current list:

  • lippurple (no tcl-config.sh)
  • ldns (can't find openssl)
  • opencv (Python.h)
  • fontforge (Python.h)
  • libstfl (Can't find Ruby.h)
  • gdal. (Can't find numpy/*.h)
@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Aug 22, 2012

Contributor

See #14371

Contributor

adamv commented Aug 22, 2012

See #14371

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Aug 22, 2012

Contributor

I could add other (perhaps more severe cases) to your list.
But Python.h, Ruby.h can easily be solved by brew install python ruby.

For these cases, I'd prefer

depends_on 'python' unless MacOS::clt.installed?

instead of depends_on :clt (assuming depends_on 'python' means homebrew's python and not any)

Contributor

samueljohn commented Aug 22, 2012

I could add other (perhaps more severe cases) to your list.
But Python.h, Ruby.h can easily be solved by brew install python ruby.

For these cases, I'd prefer

depends_on 'python' unless MacOS::clt.installed?

instead of depends_on :clt (assuming depends_on 'python' means homebrew's python and not any)

@mxcl

This comment has been minimized.

Show comment Hide comment
@mxcl

mxcl Aug 22, 2012

Member

As much as I want wo/CLT to work I'm reluctant to litter formula with special case handling.

I actually solved the Python.h ones in superenv, but gdal proved it is a inadequate fix. Depending on brew/python works but then you are adding a massive dep. Really it should remove the python features. But then you should support that and the alternative etc. So it's tonnes of special handling for a minority of users.

Member

mxcl commented Aug 22, 2012

As much as I want wo/CLT to work I'm reluctant to litter formula with special case handling.

I actually solved the Python.h ones in superenv, but gdal proved it is a inadequate fix. Depending on brew/python works but then you are adding a massive dep. Really it should remove the python features. But then you should support that and the alternative etc. So it's tonnes of special handling for a minority of users.

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Aug 22, 2012

Contributor

It isn't that bad as you describe and will get better over time because upstream devs will also notice that many people have Xcode but not the CLTs or the other way around.

I still haven't had the time to really understand what your superenv does.

Contributor

samueljohn commented Aug 22, 2012

It isn't that bad as you describe and will get better over time because upstream devs will also notice that many people have Xcode but not the CLTs or the other way around.

I still haven't had the time to really understand what your superenv does.

@mxcl

This comment has been minimized.

Show comment Hide comment
@mxcl

mxcl Aug 22, 2012

Member

I find it very unlikely that upstream devs will support Xcode without CLT. Why should they? It's complicated and not designed for anything but the Xcode IDE. Also it's subject to change every release.

Maybe it's not as bad as I say, but based on my work the last week or so, I certainly think there are categories of problems that are not solved easily.

I use Xcode wo/CLT and will continue to on my main machine for the foreseeable future. But I wouldn't recommend it, and I have another machine for testing which is CLT wo/Xcode.

Member

mxcl commented Aug 22, 2012

I find it very unlikely that upstream devs will support Xcode without CLT. Why should they? It's complicated and not designed for anything but the Xcode IDE. Also it's subject to change every release.

Maybe it's not as bad as I say, but based on my work the last week or so, I certainly think there are categories of problems that are not solved easily.

I use Xcode wo/CLT and will continue to on my main machine for the foreseeable future. But I wouldn't recommend it, and I have another machine for testing which is CLT wo/Xcode.

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Aug 22, 2012

Contributor

Probably you are right :-)

I use Xcode wo/CLT and will continue to on my main machine for the foreseeable future. But I wouldn't recommend it, and I have another machine for testing which is CLT wo/Xcode.

100% agree. Same for me.
Still a bit sad that Apple did removed the CLT just to spare 150 megs.

Contributor

samueljohn commented Aug 22, 2012

Probably you are right :-)

I use Xcode wo/CLT and will continue to on my main machine for the foreseeable future. But I wouldn't recommend it, and I have another machine for testing which is CLT wo/Xcode.

100% agree. Same for me.
Still a bit sad that Apple did removed the CLT just to spare 150 megs.

@mxcl

This comment has been minimized.

Show comment Hide comment
@mxcl

mxcl Aug 22, 2012

Member

Still a bit sad that Apple did removed the CLT just to spare 150 megs.

I think it was motivated by:

  1. Xcode needing to be just the .app bundle for the App Store
  2. Wanting to distribute the CLT separately.

Once you've done both of these. You don't want to install the CLT by default when the .app opens as users will demand that it be optional. And then you have what you have.

Member

mxcl commented Aug 22, 2012

Still a bit sad that Apple did removed the CLT just to spare 150 megs.

I think it was motivated by:

  1. Xcode needing to be just the .app bundle for the App Store
  2. Wanting to distribute the CLT separately.

Once you've done both of these. You don't want to install the CLT by default when the .app opens as users will demand that it be optional. And then you have what you have.

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Aug 22, 2012

Contributor

distribute the CLT separately

... which is great but (when I checked last) a normal Apple-ID was not sufficient to download.

Contributor

samueljohn commented Aug 22, 2012

distribute the CLT separately

... which is great but (when I checked last) a normal Apple-ID was not sufficient to download.

@jacknagel

This comment has been minimized.

Show comment Hide comment
@jacknagel

jacknagel Aug 31, 2012

Contributor

Applied @samueljohn's pull request to my deps branch; #14456.

Contributor

jacknagel commented Aug 31, 2012

Applied @samueljohn's pull request to my deps branch; #14456.

This comment has been minimized.

Show comment Hide comment
@ghost

ghost Aug 31, 2012

Might this be the cause of me not being able to install Mercurial w/o CLT?

Ed1t: Can't find Python headers. This also include with # pip install mercurial.

ghost commented Aug 31, 2012

Might this be the cause of me not being able to install Mercurial w/o CLT?

Ed1t: Can't find Python headers. This also include with # pip install mercurial.

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Aug 31, 2012

Contributor

Thanks @jacknagel!

Perhaps we have to fix mercurial to deal with system python's moved headers on Xcode ony systems.
If you don't mind installing brewed python - it would fix that, @MindTooth .

Contributor

samueljohn commented Aug 31, 2012

Thanks @jacknagel!

Perhaps we have to fix mercurial to deal with system python's moved headers on Xcode ony systems.
If you don't mind installing brewed python - it would fix that, @MindTooth .

This comment has been minimized.

Show comment Hide comment
@ghost

ghost Aug 31, 2012

Would mean I need to install Xquartz. Not that I wan't to be difficult, but if I can manage with only Xcode.app, I'm quite happy with that :) But, I have no intention to add more work if people see it unfit. I respect the work going into this :)

ghost commented Aug 31, 2012

Would mean I need to install Xquartz. Not that I wan't to be difficult, but if I can manage with only Xcode.app, I'm quite happy with that :) But, I have no intention to add more work if people see it unfit. I respect the work going into this :)

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Aug 31, 2012

Contributor

Pythons uses Tk and Tk, in turn, includes one or two headers from X. If we make Tk an option we could get rid of X. But tk is still kind of the default GUI. Or we find that X is perhaps not really needed at all. But how to patch?

Contributor

samueljohn commented Aug 31, 2012

Pythons uses Tk and Tk, in turn, includes one or two headers from X. If we make Tk an option we could get rid of X. But tk is still kind of the default GUI. Or we find that X is perhaps not really needed at all. But how to patch?

@mxcl

This comment has been minimized.

Show comment Hide comment
@mxcl

mxcl Aug 31, 2012

Member

Consider this the definite default for Homebrew: --without-X (when possible).

Member

mxcl commented Aug 31, 2012

Consider this the definite default for Homebrew: --without-X (when possible).

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Sep 1, 2012

Owner

@mxcl If that's the case I'll bear that in mind for anything non-gtk.

Owner

MikeMcQuaid commented Sep 1, 2012

@mxcl If that's the case I'll bear that in mind for anything non-gtk.

@mxcl

This comment has been minimized.

Show comment Hide comment
@mxcl

mxcl Sep 1, 2012

Member

When possible, and practical. Obviously stuff that needs X to be useful should depend on X.

Member

mxcl commented Sep 1, 2012

When possible, and practical. Obviously stuff that needs X to be useful should depend on X.

@mxcl

This comment has been minimized.

Show comment Hide comment
@mxcl

mxcl Sep 1, 2012

Member

The reason for this new attitude is: X is no longer readily available. And it sucks.

Member

mxcl commented Sep 1, 2012

The reason for this new attitude is: X is no longer readily available. And it sucks.

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Sep 1, 2012

Contributor

Note that things that "depend_on :x11" really ought to have a code comment reminding us why

Contributor

adamv commented Sep 1, 2012

Note that things that "depend_on :x11" really ought to have a code comment reminding us why

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Sep 1, 2012

Owner

I'm working on it. Very little stuff justifiably needs to depend on X11. Longer term I'd say that stuff should be in another tap anyway.

Owner

MikeMcQuaid commented Sep 1, 2012

I'm working on it. Very little stuff justifiably needs to depend on X11. Longer term I'd say that stuff should be in another tap anyway.

This comment has been minimized.

Show comment Hide comment
@ghost

ghost Sep 23, 2012

If I installed OpenSSL, and I pointed ldns like so:

./configure --prefix=/usr/local/Cellar/ldns/1.6.13 --with-drill --with-ssl=/usr/local/Cellar/openssl/1.0.1c

It worked just fine for no_clt. Also added depends_on 'openssl'. This will of course break if OpenSSL upgrades, so maybe it's a dead end.

(Though I expect everyone in here to know this already, with how building software works :P )

P.S.: Read this about OpenSSL being somewhat deprecated in Lion: http://ludovicrousseau.blogspot.no/2011/08/mac-os-x-lion-and-openssl.html

ghost commented Sep 23, 2012

If I installed OpenSSL, and I pointed ldns like so:

./configure --prefix=/usr/local/Cellar/ldns/1.6.13 --with-drill --with-ssl=/usr/local/Cellar/openssl/1.0.1c

It worked just fine for no_clt. Also added depends_on 'openssl'. This will of course break if OpenSSL upgrades, so maybe it's a dead end.

(Though I expect everyone in here to know this already, with how building software works :P )

P.S.: Read this about OpenSSL being somewhat deprecated in Lion: http://ludovicrousseau.blogspot.no/2011/08/mac-os-x-lion-and-openssl.html

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 1, 2012

Contributor

Is depends_on :clt still a needed option? This thread seems to have drifted from the subject line.

Contributor

adamv commented Oct 1, 2012

Is depends_on :clt still a needed option? This thread seems to have drifted from the subject line.

@mxcl

This comment has been minimized.

Show comment Hide comment
@mxcl

mxcl Oct 1, 2012

Member

Some formula need it. Or need to be hacked copiously.

Member

mxcl commented Oct 1, 2012

Some formula need it. Or need to be hacked copiously.

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Oct 21, 2012

Contributor

Closing in anticipation of #14456 which includes a patch for this.

Contributor

adamv commented Oct 21, 2012

Closing in anticipation of #14456 which includes a patch for this.

@adamv adamv closed this Oct 21, 2012

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.