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

Use GitHub actions to automatically build libpinproc #14

Open
tomlogic opened this issue Aug 4, 2020 · 12 comments
Open

Use GitHub actions to automatically build libpinproc #14

tomlogic opened this issue Aug 4, 2020 · 12 comments

Comments

@tomlogic
Copy link
Contributor

tomlogic commented Aug 4, 2020

We should be able to use GitHub actions to build libraries for distribution so others don't need to. We can then tag specific commits as "official" releases.

I'd like to see automated builds for the libraries used in PinMAME, but we could also identify common platforms and have automated libpinproc builds feed into automated pypinproc builds if that makes it easier for developers to start coding in MPF, SkeletonGame and other platforms.

@horseyhorsey
Copy link

Need this, it is painful trying build on windows...I don't think I've ever managed, always gave up.

I made a start on the Linux/Mac but getting errors on the "libfti". You'd be more familiar with that than me and to clean up. If get past that it will build...

https://github.com/horseyhorsey/libpinproc/actions/runs/1767393834

I'll make a start on windows, that's what I'm after as can't run the board with the existing dll that is floating around.

@tomlogic
Copy link
Contributor Author

Have you tried some of the libftdi Ubuntu packages? https://packages.ubuntu.com/search?keywords=libftdi

It seems like libftdi1-dev might work.

When I was using Windows, I was working with PinMAME in Visual Studio and building libpinproc with Visual Studio made the most sense at the time. My last round of changes at least removed the yaml-cpp dependency.

@tomlogic
Copy link
Contributor Author

You might be able to make use of the pre-built files for Windows in the PinMAME repository.

https://github.com/vpinball/pinmame/tree/master/ext/pinproc

@horseyhorsey
Copy link

Great, thanks Tom for quick reply, will try that package, I have a good feeling that will do it. I got it to build on a raspberry pi but slightly different on the ftdi install.

Yes I was close there and got as far as producing a solution but it's probably the ftdi again and possibly it's include location.

I am green with linux and building C, I always get traumatized by it so like now, so I only do it when I have to 😅. Just to be able to download the lib would be heaven right now.

@horseyhorsey
Copy link

You might be able to make use of the pre-built files for Windows in the PinMAME repository.

https://github.com/vpinball/pinmame/tree/master/ext/pinproc

I see thanks, will take a look. I got back to where I was before after installing the package from ubuntu. It's about 70% in and it fails building the test project.

/usr/bin/ld: cannot find -lftdi1

@horseyhorsey
Copy link

Got it built by installing Cygwin and installed the package libftdi which does the libusb.

I had to manual copy a ft2xx.h to libpinproc/include/ft2xx.h and also a ft2xx.lib next to the solution.

Cygwin and MinGW install is painful slow in the workflows, that's fine if it's building, but testing that is consuming.

@koenheltzel
Copy link
Contributor

koenheltzel commented Jan 30, 2022

For Linux check out this script from the MPF team:
https://github.com/missionpinball/mpf-debian-installer/blob/dev/install-proc
Used it this week without trouble (I only used this install-proc script, not the others as I don't use MPF). Although it uses their own forks of libpinproc and pypinproc.
Windows is trickier indeed and I would be welcoming an automated build process very much.

@horseyhorsey
Copy link

I see thanks for pointing that out, I did manage to build workflow there but didn't add building a package.

I will come back to that and the windows now that I've been balls deep in it, but I think need to implement PDLED first.

@tomlogic
Copy link
Contributor Author

I see thanks, will take a look. I got back to where I was before after installing the package from ubuntu. It's about 70% in and it fails building the test project.

/usr/bin/ld: cannot find -lftdi1

You might need to install libftdi1 in addition to libftdi1-dev?

In the work you're doing, be sure to include a README that provides some background on how the automated builds work, and how users can test the scripts locally. Even if it's just a URL to a page that provides those details. Once you get things working well for Linux and Windows, I can try updating the scripts for Mac (if they aren't already working for that platform).

@horseyhorsey
Copy link

I see thanks, will take a look. I got back to where I was before after installing the package from ubuntu. It's about 70% in and it fails building the test project.
/usr/bin/ld: cannot find -lftdi1

You might need to install libftdi1 in addition to libftdi1-dev?

In the work you're doing, be sure to include a README that provides some background on how the automated builds work, and how users can test the scripts locally. Even if it's just a URL to a page that provides those details. Once you get things working well for Linux and Windows, I can try updating the scripts for Mac (if they aren't already working for that platform).

No problem, it is building linux/mac now but it needs a creating build / package script, I have kept the workflow action to work on again but I wanted to get a couple of small changes in first, so that fork was cleared

To be honest, the .yaml that is created is fairly explanatory, you're just setting up an environment and piping commands but adding a readme in there documenting each yaml file for a brief overview would never go a miss.

I have never run locally, I think it will take you more time trying to set that up than it would to script a build and test it. There is (by all accounts) a decent one named act-cli, but it's all Docker based for a good reason I guess.

@horseyhorsey
Copy link

The windows one came out better than before, cleaner and just takes a couple of minutes.

Win32-Release
https://github.com/horseyhorsey/libpinproc/actions/runs/1770136708

I'm not happy about dumping the ftd.lib and header in source but just for now because it is PITA.

There should be somewhere on the build runner that those two files are available so they could be copied instead or putting somewhere libpinproc picks them up. I think my local solution also has the ftds copied

@horseyhorsey
Copy link

horseyhorsey commented Oct 12, 2023

:) It's funny reading that back. It was more or less the same experience this time round. Quite painful trying to build for all platforms but certainly is possible with more build experience.

I've added 4 workflows which covers the windows 32/64, linux mac. No change in code or makefiles. If FTDI is needed, like in windows, then it's downloaded and files copied to build it. I have tested both x86/x64 on windows good.
https://github.com/FlippingFlips/libpinproc/actions

After they build published to release:
https://github.com/FlippingFlips/libpinproc/releases

I have tested all different runners, the best is ubuntu for speed, so if you could cross compile using that it would be nice. The closest I get for cross compile is using MYSYS, mingw but have issues with ftdilib after adding the missing header. It would be handy to have them all including arm and may come and revisit at some point but it is time consuming and a ballache :).

image

Edit:
Even though mac, linux build with no errors the shared lib is empty. Can see what is going on there it's creating a "*.so.2.1" so renaming to ".so" is good

image

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

No branches or pull requests

3 participants