Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setupext: put pkg-config -I, -L, -l locations at the head of the list #2623

Merged
merged 1 commit into from Nov 30, 2013

Conversation

efiring
Copy link
Member

@efiring efiring commented Nov 28, 2013

This addresses #2622.
The assumption here is that we want the pkg-config info to take
precedence, so its -I and -L output should be prepended, not
appended to the lists used to construct the compiler and linker
commands. It is less clear whether the -l info also should
be prepended, as it is in the changeset; ideally, it wouldn't
matter, but for some compilers, it might. If so, -l can
be handled separately from -I and -L.

The assumption here is that we want the pkg-config info to take
precedence, so its -I and -L output should be prepended, not
appended to the lists used to construct the compiler and linker
commands.  It is less clear whether the -l info also should
be prepended, as it is in the changeset; ideally, it wouldn't
matter, but for some compilers, it might.  If so, -l can
be handled separately from -I and -L.
@mdboom
Copy link
Member

mdboom commented Nov 29, 2013

Let's make it all prepended, I think, for now, as you've done.

Note to self: This should be cherry-picked to the 1.3.x branch.

efiring added a commit that referenced this pull request Nov 30, 2013
setupext: put pkg-config -I, -L, -l locations at the head of the list
@efiring efiring merged commit b92492e into matplotlib:master Nov 30, 2013
efiring added a commit that referenced this pull request Dec 2, 2013
setupext: put pkg-config -I, -L, -l locations at the head of the list
@mdboom
Copy link
Member

mdboom commented Dec 2, 2013

Cherry-picked as 4af8015

@cbrnr
Copy link
Contributor

cbrnr commented Feb 7, 2014

Is this going to get into 1.3.2? Because right now, doing a standard
pip install matplotlib
fails exactly for this reason (besides another problem which prevents people from using this exact command, see #2715). Also, I think this is pretty urgent and a quick release would be nice.

@mdboom
Copy link
Member

mdboom commented Feb 7, 2014

Yes, this will be in 1.3.2, if one is made.

@cbrnr
Copy link
Contributor

cbrnr commented Feb 9, 2014

Hm, this sounds rather vague given that this is a pretty nasty show-stopper. After all, people won't be able to pull in matplotlib if they're using pip. Given that there were about 2 months between 1.3.0 and 1.3.1, and it's now been almost 4 months since 1.3.1, what are the chances that 1.3.2 will be releases very soon?

@benesch
Copy link

benesch commented Mar 23, 2014

+1 it'd be super awesome if we could get a 1.3.2 with this fix

@tacaswell
Copy link
Member

@benesch Why would you prefer a 1.3.2 over using a 1.4.0?

@benesch
Copy link

benesch commented Mar 23, 2014

Oh, I'm all for a 1.4.0! I just took a quick glance at the milestones and 1.3.2 seemed more feasible than a 1.4.0, but I'm not familiar with the matplotlib development cycle.

(It just really sucks that pip install matplotlib fails hard on OS X.)

Anyway, thanks for all your hard work!

@efiring efiring deleted the include_order branch November 23, 2014 21:15
@kevinsoucy
Copy link

sudo apt-get install libfreetype6-dev
sudo pip install matplotlib --upgrade

DONE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants