Opened 5 years ago

Closed 5 years ago

#10289 closed defect (fixed)

"make install" doesn't install flashproxy-common modules

Reported by: dcf Owned by:
Priority: Low Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: infinity0 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Makefile.client has make install but it doesn't install the modules.

~/flashproxy$ sudo make install
make: *** No rule to make target `install'.  Stop.

~/flashproxy$ sudo make -f Makefile.client install
mkdir -p /usr/local/bin
install flashproxy-client flashproxy-reg-appspot flashproxy-reg-email flashproxy-reg-http flashproxy-reg-url /usr/local/bin
mkdir -p /usr/local/share/doc/flashproxy-client
install -m 644 README LICENSE ChangeLog torrc /usr/local/share/doc/flashproxy-client
mkdir -p /usr/local/share/man/man1
install -m 644 doc/flashproxy-client.1 doc/flashproxy-reg-appspot.1 doc/flashproxy-reg-email.1 doc/flashproxy-reg-http.1 doc/flashproxy-reg-url.1 /usr/local/share/man/man1

~/flashproxy$ flashproxy-client 
Traceback (most recent call last):
  File "/usr/local/bin/flashproxy-client", line 22, in <module>
    from flashproxy.util import parse_addr_spec, format_addr
ImportError: No module named flashproxy.util

Child Tickets

Change History (5)

comment:1 Changed 5 years ago by dcf

It works after I run a separate

sudo python setup-common.py install

comment:2 Changed 5 years ago by infinity0

This is intended, so that separate build scripts are responsible for installing separate components.

We can add an install target to the plain Makefile to install both the client and the common library, but I didn't think users would want to do this normally, since the binary tarball built by make dist can already be run in-place.

comment:3 in reply to:  2 ; Changed 5 years ago by dcf

Replying to infinity0:

This is intended, so that separate build scripts are responsible for installing separate components.

That is bogus. The rigid separation of components is helpful for packagers and no one else. make -f Makefile.client install should give me a working installation, not just copy a bunch of useless files.

I want to install flashproxy-client to somewhere in my path so that I can test obfs-flash-client. What's the procedure to do that?

Why can't installing flashproxy-client also install flashproxy-common (and installing facilitator also install flashproxy-common)? Even if there are separate makefiles/setup.py for different components, they may call each other.

comment:4 in reply to:  3 Changed 5 years ago by infinity0

Replying to dcf:

Replying to infinity0:

This is intended, so that separate build scripts are responsible for installing separate components.

That is bogus. The rigid separation of components is helpful for packagers and no one else. make -f Makefile.client install should give me a working installation, not just copy a bunch of useless files.

I'll add a make install target in the top-level normal Makefile. This is more appropriate than adding it to Makefile.client.

I want to install flashproxy-client to somewhere in my path so that I can test obfs-flash-client. What's the procedure to do that?

In the meantime you can add the appropriate entry to your PATH, or set FLASHPROXY_CLIENT when running obfs-flash-client.

Why can't installing flashproxy-client also install flashproxy-common (and installing facilitator also install flashproxy-common)? Even if there are separate makefiles/setup.py for different components, they may call each other.

It's generally not a good idea to handle dependencies within a component, otherwise you get the diamond problem. Here, if facilitator / Makefile.client installs flashproxy-common automatically, you'll end up installing it twice, which might be problematic. It's also not good for any overall-packaging scripts (which is the correct place to handle dependencies).

comment:5 Changed 5 years ago by dcf

Resolution: fixed
Status: newclosed

Thanks, it works for me now.

Note: See TracTickets for help on using tickets.