[Privoxy-devel] OK to move the winsetup dir under current?

[Lee]

On 8/28/17, Fabian Keil <fk at fabiankeil.de> wrote:
> Lee <ler762 at gmail.com> wrote:
>
>> On 8/16/17, Fabian Keil <fk at fabiankeil.de> wrote:
>
>> > I wouldn't object to the GPLv2-licensed source code and icons in
>> > winsetup being moved over to current, though, as there don't seem
>> > to be a lot of files compared to the windows-specific files that are
>> > already there.
>> >
>> > Of course this wouldn't reduce the gymnastics required to
>> > build a windows release with installer.
>>
>> What if nsis.exe becomes just another program that the user is
>> responsible for downloading/installing - ie. the same deal as sed,
>> awk, perl, gcc, etc.
>
> Sounds good to me.
>
>> I dunno how much emphasis is placed on backwards compatibility by the
>> nsis group, so we keep the current winsetup/nsis around for the
>> official win32 builds and tell users they can download the nsis
>> executable from us or the official project site (with a note about
>> possible compatibility issues?)
>
> If the binary (or another version that works) is still available
> from the official project site, it seems sufficient to me to document
> this and mention the version and checksum of the file that was used
> to create the Privoxy release builds.

Sufficient, but much more difficult - I see a lot of value in ease of
use & low 'barriers to entry'.  Along with I'd prefer not to have to
document how to get, install & use NSIS when building privoxy or deal
with user problems when they use a different version of NSIS for
building their version of privoxy.

My wife just got a new windows laptop, so I gave her the 'how to build
privoxy' documentation I've been working on to see if it's complete,
easy to follow, etc.  It's *so* much easier to tell someone:
- run the cygwin setup program from <here>
- install these things
- create a SF account
- open a cygwin terminal window & do
   mkdir /source
   mkdir /source/privoxy
   cd /source/privoxy
   cvs -z3 -d:extssh:SFUSERID at ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co .
   cd winsetup
   make
- from the windows file explorer, double-click on
    \cygwin\source\privoxy\winsetup\privoxy_setup.exe
  to install privoxy

Even something as trivial as verifying the checksum is a pain in
Windows; I don't remember this in W7 & it definitely doesn't exist in
Vista, but the Windows 10 file explorer has a right-click CRC-SHA
option that will _show_ you the SHA-1 or SHA-256 checksum of a file.
**show** as in you can't copy the displayed checksum to the clipboard,
so it's a pain in the ass to compare the checksum displayed on a
website or in a text file against the checksum displayed in that
stupid little checksum window (it's kind of obvious I loathe windows
10 - right :)

Another thing is maintaining the documentation.  Take a look at
winsetup/privoxy_winthreads.nsi
; Purpose:
;   NSIS script to make the Privoxy installer
;
;   This .NSI script is designed for NSIS v2.24+
;
;   Get NSIS from:  http://www.nullsoft.com/free/nsis/

goto        http://www.nullsoft.com/free/nsis/
end up at http://www.winamp.com/free/nsis/
and see:
Not Found
The requested URL /free/nsis/ was not found on this server.

It turns out that NSIS is hosted on sourceforge now
http://nsis.sourceforge.net/Main_Page

The chances are pretty good that NSIS isn't going to move anytime
soon, but still... making the adjustment after cygwin gcc dropped the
'-mno-cygwin' flag was a pain.  If we continue hosting the nsis binary
used to build privoxy it seems like that could avoid future pain
if/when things change later on.


>> The existing winsetup/
>>   GNUmakefile
>>   privoxy.ico
>>   privoxy_winthreads.nsi
>>   readme.txt   (changes TBD)
>>   uninstall_privoxy.ico
>> gets moved to a new current/win32 directory and the appropriate
>> adjustments are made to current/win32/GNUmakefile to
>>   set the correct source dir (SOURCE   = ../)
>>   set MAKENSIS if not already set & check the program exists ( -x
>> $MAKENSIS ???)
>
> Sounds good to me. It should probably be done after the git migration,
> though, so the history isn't lost.

oh joy, I get to learn git now :)

> I intent to request the missing preferred git ids in the next
> couple of days and finally migrate the current repository in
> September.

OK
Lee