How to install Python package from source on Windows

Chris Angelico rosuav at gmail.com
Thu May 18 14:50:16 EDT 2017


On Fri, May 19, 2017 at 3:11 AM, Steve D'Aprano
<steve+python at pearwood.info> wrote:
> On Thu, 18 May 2017 11:38 pm, bartc wrote:
>> OK, same url but with '32' instead:
>>
>>         https://github.com/bartg/langs/blob/master/qlang/qcc32.c
>>         https://github.com/bartg/langs/blob/master/qlang/pcc32.c
>
> https://duckduckgo.com/html/?q=how%20to%20download%20code%20from%20github
>
> Dear gods, I'm reduced to getting technical advice from a WordPress site...

Ouch.

> Okay, apparently I have to find the top level of the repository, and
> append ".git" to the URL...
>
> ...there's no qlang repository... ah this looks like it:
>
> https://github.com/bartg/langs.git

To be fair, "appending .git to the URL" isn't necessary. If you're at
the repository's base URL, you can clone that as is. But since bart
has no real experience with git, I rather doubt that he expected you
to clone this using git. He expected you to obtain the source code,
uhh... somehow.

Actually his use of git would be considered abominable, except that he
basically isn't using git at all. I tried to search for the over-large
number that triggered your warning, and didn't find it in the "real"
source files, but found that the (checked-in) intermediate files are
utterly useless for humans. Consider this commit:

https://github.com/bartg/langs/commit/12cf5b7311e98fde3503cfd1d709603dc6cc2e17

(Sorry Steve, but I don't have any better way to share the commit than
a GitHub link. You can use "git show 12cf5b" if you already have the
repo cloned though.)

> Finally:
>
> git clone https://github.com/bartg/langs.git
>
>
> That works! Now, using my awesome deductive powers from 20+ years of using
> Linux, I realise that I must cd into the the "langs" directory. Good thing
> I'm not a beginner, hey?

That cd is specific to your git-based code acquisition. Since bart
brags that you can compile this as a single file, he probably expected
you to download just that one file into /usr/bin and compile it right
there.

> Where's your build documentation? I tried reading the README file, but it
> was useless. qlang/readme.md was just as useless.
>
> qlang/Instructions.md has some vague instructions for building the 64-bit
> version. Using my awesome powers of deduction, I reckon that changing 64 to
> 32 should work...
>
>
> Quote:
>     ### Download Q compiler as qcc64.c, Q interpreter as pcc.64
>
> Well, I cloned the entire repo. Does that count as downloading? Do I need to
> rename the files? Who the hell knows?

-- see above.

To be fair, most of what you're seeing here is very common with small
projects that haven't been widely deployed. Smooth installation
instructions take time, effort, and many MANY different people's
deployment. Your criticisms would be considered rather inappropriate
and out of place - except that he's been moaning about CPython's
installation instructions.

> [steve at ando langs]$ gcc -m32 -O3 qlang/qcc32.c -oqcc -lm
> qlang/qcc32.c:13808:23: warning: integer constant is so large that it is
> unsigned
> qlang/qcc32.c: In function ‘do_tag’:
> qlang/qcc32.c:13808: warning: this decimal constant is unsigned only in ISO
> C90
>
>
> Hmmm, that's a bit scary... I mean, Python is used by millions of people. I
> can afford to trust it even if it generates warnings, because if they were
> serious, somebody would have noticed by now. But a single-user project from
> somebody I don't know? I'm less inclined to trust code I don't know that
> generates warnings I don't understand.

Unfortunately, this is true of a *lot* of code out there. GCC's
warnings are incredibly extensive, and a lot of them are about
specific revisions of the ISO standard (so they'll disappear if you
add "--std=c99" or something). If bart didn't himself use GCC, the
chances that his code will compile warning-free are almost zilch.
Doesn't necessarily mean the code's wrong. In this particular
instance, gcc is cautioning you that -2**63 is the same as 2**63 when
your 'long long' type is a 64-bit one. I'm not sure what that number
is used for, though, as it doesn't show up in the "actual sources".

> That at least completed without any warnings. Hmmm... that reminds me...
>
>
> [steve at ando langs]$ gcc -Wall -m32 -O3 qlang/pcc32.c -opcc -lm
>
> [wall of text]
>
> Holy mother of perl! Look at all those warnings! Uninitialised variables,
> unsafe dereferencing of type-punned pointers, missing parentheses, unused
> variables and labels, confusion between int and longint...

Now this, however, is more serious. Those warnings scare me, too. (I
just tried it.) Instead of being "gcc is noisy", these are "your code
is sloppy". These are exactly why I tell most people NOT to write in
C. For machine-generated code, this is IMO unacceptable. Maybe
"-Wno-unused" is okay (machine-generated code often has some junk in
it), but all the uninitialized variables? No way. Doesn't matter what
compiler you use, run it in all-warnings-enabled mode at least once as
part of testing your codegen.

ChrisA



More information about the Python-list mailing list