Announcement

Collapse
No announcement yet.

LMS for Windows using Strawberry Perl

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    LMS for Windows using Strawberry Perl

    Oh, one more thing: do you have your WIP code somewhere in a git repository?
    Michael

    "It doesn't work - what shall I do?" - "Please check your server.log and/or scanner.log file!"
    (LMS: Settings/Information)

    Comment


      #17
      Originally posted by mherger View Post
      >
      "you have to install Perl" might scare people away. I think that really
      is it.
      I've been having folks install Strawberry Perl (and prior to that, ActivePerl) for 10 years. It's not that big a deal for them.

      Originally, I advised for the Portable version, but changed course on that years ago and recommend the installed version. It's just easier to write documentation.

      Further, I have a script that cpanm's the required modules necessary for my various software packages. That seems to be sufficient.

      However, for what I'm doing, typically using the latest Perl and modules is OK, but there are times when I've had to advise a particular version becomes some module fails on the most recent S.P. But this is generally pretty rare.

      Comment


      • #18
        LMS for Windows using Strawberry Perl

        Just chiming in...

        I have long term experience with preparing user-friendly deliverables for
        complex perl programs. Basically it is a way of packaging perl, the
        necessary libraries and modules and the rest of the code/data in a
        directory structure (kind of virtual environment) and using a specially
        built version of perl that stays inside the virtual environment. The whole
        thing is then packaged using InnoSetup (Windows), dmg (MacOS) or Appimage
        (Linux).

        >From the user perspective, she downloads an installer (e.g. Windows .exe

        file), runs it and its contents is installed where the user wants (usually
        C:\Program Files (x86)\) together with icons on the deskstop to
        start the program.

        I use this a.o for the ChordPro program. Feel free to download an installer
        from https://github.com/ChordPro/chordpro...ownload/R5.985
        and see how it works.

        Important: Getting the packaging right can be a bit tedious. But once it
        is done building new kits it is a whimp.

        -- Johan

        Comment


        • #19
          LMS for Windows using Strawberry Perl

          On Wed, 2 Feb 2022 19:46:22 +0100, Johan Vromans <jvromans (AT) squirrel (DOT) nl>
          wrote:

          > Important: ...


          Also important: There is no run-time overhead (no on-the-fly unpacking into
          hidden folders).

          Comment


            #20
            Originally posted by mherger View Post
            No. I'm even open to dropping all the helpers.
            Thanks. I'll keep that in mind going forward.

            Originally posted by mherger View Post
            "you have to install Perl" might scare people away. I think that really
            is it.

            So I was wondering whether we could have two installers: the "full"
            version bundling Strawberry Perl with LMS. And the LMS only installer
            (used in updates), only installing the LMS code. I haven't looked into
            Strawberry Perl's licensing and what not. Just an idea.
            I'd been thinking along those lines as well.

            But if we have 2 installers, why not just install the official strawberry perl msi once as MrC has identified from experience?

            The LMS installer should be able to be changed to handle the dependency and install perl if it's not there, keeping in mind that we will be tied to a specific version of SB Perl, just like Linux.

            Originally posted by mherger View Post
            > Setting up lms as a windows service works using 'NSSM'
            > (https://nssm.cc/) running perl.exe, slimserver.pl and parameters
            > directly in the service definition.[/color]

            What's the licensing model there?
            Yes, I am aware of possible licensing issues, not specifically with the NSSM, but in general. It's always a concern, but I've not investigated any of that yet.


            Originally posted by mherger View Post
            If I may say so... I'd prefer you to work on a simple, stable
            installation procedure leveraging raw Strawberry Perl, than wasting time
            trying to figure out the issues with building binaries.
            Yes of course. I'd appreciate your direction as we move along.

            Originally posted by mherger View Post
            Great! An they would only be include once, not once per binary!

            I know that you don't use Cygwin. But how are the chances that the build
            process would still work with Cygwin? It would be great if I didn't have
            to maintain another build host...
            Currently, I just add the unix util folder location to the PATH before running buildme. I only have the commands needed for buildme to success, it's only 9MB, no installer, no extra cruft.

            However, I have no issues with moving to as close as possible to the current win32 build system. In which case it would be helpful to have the version details for all the tools, sans the PDK of course.

            Originally posted by mherger View Post
            Oh, one more thing: do you have your WIP code somewhere in a git repository?
            I've added a link in the first post to the platform wip sources.
            Ralphy

            1-Touch, 5-Classics, 3-Booms, 2-UE Radio
            Squeezebox client builds donations always appreciated.

            Comment


              #21
              Originally posted by [email protected] View Post
              Just chiming in...

              I have long term experience with preparing user-friendly deliverables for
              complex perl programs. Basically it is a way of packaging perl, the
              necessary libraries and modules and the rest of the code/data in a
              directory structure (kind of virtual environment) and using a specially
              built version of perl that stays inside the virtual environment. The whole
              thing is then packaged using InnoSetup (Windows), dmg (MacOS) or Appimage
              (Linux).

              >From the user perspective, she downloads an installer (e.g. Windows .exe

              file), runs it and its contents is installed where the user wants (usually
              C:\Program Files (x86)\) together with icons on the deskstop to
              start the program.

              I use this a.o for the ChordPro program. Feel free to download an installer
              from https://github.com/ChordPro/chordpro...ownload/R5.985
              and see how it works.

              Important: Getting the packaging right can be a bit tedious. But once it
              is done building new kits it is a whimp.

              -- Johan
              Thank you for the suggestion. Unfortunately, that link returns a 404.

              I tried looking into ChordPro in the beginning but it appears to be a dead project, or perhaps, they've just moved development.

              Please correct me if I'm mistaken.

              Originally posted by [email protected] View Post
              On Wed, 2 Feb 2022 19:46:22 +0100, Johan Vromans <jvromans (AT) squirrel (DOT) nl>
              wrote:

              > Important: ...


              Also important: There is no run-time overhead (no on-the-fly unpacking into
              hidden folders).
              Yes this is actually very painful. Especially the first time you run a new build.

              The AV services chews CPU for a long time scanning the thousands of files as they're expanded into the par-cache temp folder and it's repeated for every exe.
              Ralphy

              1-Touch, 5-Classics, 3-Booms, 2-UE Radio
              Squeezebox client builds donations always appreciated.

              Comment


              • #22
                LMS for Windows using Strawberry Perl

                On Thu, 3 Feb 2022 12:24:44 +0000, ralphy
                <ralphy.af9sxb (AT) no-mx (DOT) forums.slimdevices.com> wrote:

                > I tried looking into ChordPro in the beginning but it appears to be a
                > dead project, or perhaps, they've just moved development.


                ChordPro is alive and kicking ever since its conception in 1991. But there
                have been many chordpro-like projects and, indeed, many of them stalled.

                I took over the original ChordPro (called 'chord') many years ago and
                kept it going under the name 'chordii'. See
                https://www.chordpro.org/chordpro/chordpro-history/ .

                A number of years ago we started a total rewrite, in Perl, and this is very
                alive. Rapid development and an active user group.

                > Please correct me if I'm mistaken.


                You're welcome.

                Sorry for the missing link. Apparently only part of the URL was correctly
                cut/pasted. Here is a new one:


                -- Johan

                Comment


                  #23
                  LMS for Windows using Strawberry Perl

                  > The LMS installer should be able to be changed to handle the dependency
                  > and install perl if it's not there, keeping in mind that we will be tied
                  > to a specific version of SB Perl, just like Linux.


                  Good plan.

                  > However, I have no issues with moving to as close as possible to the
                  > current win32 build system. In which case it would be helpful to have
                  > the version details for all the tools, sans the PDK of course.


                  I'm not sure I understand. As you might know the buildme.pl is
                  cross-platform. On Windows whomever started the work decided to base it
                  on cygwin, maybe just for the availability of all the same tools needed.
                  Are you using the same Strawberry Perl to run the script as you use for
                  LMS? Unless we want to move the 32 bit build to the same architecture
                  (getting rid of ActiveState tools), I'd like to keep the current
                  pipeline, as otherwise we'd have to tweak it even more to cover the two
                  different builds.

                  But maybe I'm overthinking this, and it actually doesn't really matter
                  much whether we use cygwin or the tools you're using. As long as there's
                  Perl, rsync and all the other tools, it should probably run just fine in
                  both environments? Or are the paths a problem?

                  Michael

                  "It doesn't work - what shall I do?" - "Please check your server.log and/or scanner.log file!"
                  (LMS: Settings/Information)

                  Comment


                    #24
                    LMS for Windows using Strawberry Perl

                    > All sources and required changes are available in
                    > https://github.com/ralph-irving/slimserver-vendor-win64 and
                    > https://github.com/ralph-irving/slimserver-win64


                    Why didn't you fork the repositories?... this way it'll be much harder
                    to merge them. The two repositories could easily get out of sync...
                    Michael

                    "It doesn't work - what shall I do?" - "Please check your server.log and/or scanner.log file!"
                    (LMS: Settings/Information)

                    Comment


                      #25
                      LMS for Windows using Strawberry Perl

                      >> All sources and required changes are available in
                      >> https://github.com/ralph-irving/slimserver-vendor-win64 and
                      >> https://github.com/ralph-irving/slimserver-win64

                      >
                      > Why didn't you fork the repositories?... this way it'll be much harder
                      > to merge them. The two repositories could easily get out of sync...


                      I wanted to see the differences in Slim::Utils::OS::Win32 you applied -
                      but it's not easy with this setup to diff them. Would it make sense to
                      have a Win64 module or similar?
                      Michael

                      "It doesn't work - what shall I do?" - "Please check your server.log and/or scanner.log file!"
                      (LMS: Settings/Information)

                      Comment


                        #26
                        Originally posted by mherger View Post
                        > The LMS installer should be able to be changed to handle the dependency
                        > and install perl if it's not there, keeping in mind that we will be tied
                        > to a specific version of SB Perl, just like Linux.


                        Good plan.
                        Great that's settled. I can move forward now, no more compiled exes for windows.

                        Originally posted by mherger View Post
                        > However, I have no issues with moving to as close as possible to the
                        > current win32 build system. In which case it would be helpful to have
                        > the version details for all the tools, sans the PDK of course.[/color]

                        I'm not sure I understand. As you might know the buildme.pl is
                        cross-platform. On Windows whomever started the work decided to base it
                        on cygwin, maybe just for the availability of all the same tools needed.
                        Are you using the same Strawberry Perl to run the script as you use for
                        LMS? Unless we want to move the 32 bit build to the same architecture
                        (getting rid of ActiveState tools), I'd like to keep the current
                        pipeline, as otherwise we'd have to tweak it even more to cover the two
                        different builds.
                        Yes, I'm fully aware of the fact that buildme.pl is cross platform. I've added the win64 build type to it.

                        I don't see any reason to move the 32bit build. I would think that at some point we would stop providing the AS 32bit builds, since the PDK is no longer supported.
                        In my mind the win32 bit build would eventually be retired. How many 32bit windows 10+ installs are there. You've already stopped provide the windows 32bit spotty helper.

                        Originally posted by mherger View Post
                        But maybe I'm overthinking this, and it actually doesn't really matter
                        much whether we use cygwin or the tools you're using. As long as there's
                        Perl, rsync and all the other tools, it should probably run just fine in
                        both environments? Or are the paths a problem?
                        I agree that it shouldn't matter. But if I'm going to change to the cygwin tools, it should be as close as possible to the version on the current build system.
                        I've been bitten too many times, by changes to newer versions of tools that break what had been works great for years. Trying to track down what's changed is often a PITA.

                        Originally posted by mherger View Post
                        > All sources and required changes are available in
                        > https://github.com/ralph-irving/slimserver-vendor-win64 and
                        > https://github.com/ralph-irving/slimserver-win64


                        Why didn't you fork the repositories?... this way it'll be much harder
                        to merge them. The two repositories could easily get out of sync...
                        I did this because the main repo is huge and all I need right now is the windows specific binaries and modules.

                        I merge the changes from the official repo about once a week, unless, you've applied a lot of changes, then I do it more often.
                        It's easy to export my repository and merge it into a branch of the official repo, I've done it many times in the past for other projects.
                        I will do this when we're close to a working solution so I can create the pull request.
                        Last edited by ralphy; 2022-02-05, 12:49.
                        Ralphy

                        1-Touch, 5-Classics, 3-Booms, 2-UE Radio
                        Squeezebox client builds donations always appreciated.

                        Comment


                          #27
                          LMS for Windows using Strawberry Perl

                          > In my mind the win32 bit build would eventually be retired. How many
                          > 32bit windows 10+ installs are there. You've already stopped provide
                          > the windows 32bit spotty helper.


                          Correct. I don't have reliable data, unfortunately. But when I look at
                          LMS 8.x checking for updates it's about 20:1 for 64 bit vs. 32 bit.
                          Unfortunately many of those running 32 bit _could_ use 64 bit, but don't
                          for whatever reason.

                          > I agree that it shouldn't matter. But if I'm going to change to the
                          > cygwin tools, it should be as close as possible to the version on the
                          > current build system.
                          > I've been bitten too many times, by changes to newer versions of tools
                          > that break what had been works great for years. Trying to track down
                          > what's changed is often a PITA.


                          Interesting. I think I've never encountered any issue with the little we
                          use in buildme.pl. But I haven't been using cygwin on a daily basis for
                          a long time. I'm not working in a MS world any more.

                          Michael

                          "It doesn't work - what shall I do?" - "Please check your server.log and/or scanner.log file!"
                          (LMS: Settings/Information)

                          Comment


                            #28
                            Originally posted by mherger View Post
                            Correct. I don't have reliable data, unfortunately. But when I look at
                            LMS 8.x checking for updates it's about 20:1 for 64 bit vs. 32 bit.
                            Unfortunately many of those running 32 bit _could_ use 64 bit, but don't
                            for whatever reason.
                            Once we have a working 64bit windows package, creating a 32bit strawberry perl variant should be easy.

                            Originally posted by mherger View Post
                            Interesting. I think I've never encountered any issue with the little we
                            use in buildme.pl. But I haven't been using cygwin on a daily basis for
                            a long time. I'm not working in a MS world any more.
                            For me, this is a general rule, not windows specific.
                            Ralphy

                            1-Touch, 5-Classics, 3-Booms, 2-UE Radio
                            Squeezebox client builds donations always appreciated.

                            Comment


                              #29
                              Now that LMS 8.3 has been released, there are two changes I'd like to add to the slimserver code base to support strawberry perl for windows in addition to the current activestate perl. One removes the use of hard coded paths to perl.exe and the other deals with strawberry perl's use of POSIX error codes for sysread whereas activestate perl 5.14 returns WSA error codes.

                              I will create pull requests to 8.4 for these shortly.

                              The remainder of the changes are to slimserver-platform and slimserver-vendor to create the contents of Bin/MSWin32-x64-multi-thread and CPAN/arch/5.32/MSWin32-x64-multi-thread.

                              Next steps are to refactor my win64 forks of these repositories to 8.4 and get the changes committed to the official repositories so they are not lost.
                              Ralphy

                              1-Touch, 5-Classics, 3-Booms, 2-UE Radio
                              Squeezebox client builds donations always appreciated.

                              Comment

                              Working...
                              X