Docker containers for building deviation

It sounds like you are targeting these at end users, not developers. Which means I won't be using them. Even if we get a Linux image running on my desktop, running emulator builds in a VM sucks, and I have no intention of going back to that.

Being at the end of a slow DSL line makes downloading docker images painful enough that doing it just to check out something I don't expect to use isn't a priority. I'll do it at some point after things have settled down.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

PhracturedBlue replied the topic: Docker containers for building deviation

I am actually targeting these images at everyone. I plan to stop supporting any other method of building Deviation in the future. The build environment is finicky and unless the 7e/F7 goes completely to the wayside, we'll never completely get rid of the compiler-size mattering (because we're still stuck with protocol modules). If we do upgrade to a different compiler, than I want everyone to do it at the same time.
I've done the build on Windows now (using the VM) and it is quite smooth, and seems no slower than when I built though MingW (though that is subjective).

So if developers or users don't want to use the recommended build environment, that is ok, but I expect to shutdown all build issues with 'you didn't use the docker image'.

Note that I'm not there yet. This is still in a pioneering stage right now.

PhracturedBlue replied the topic: Docker containers for building deviation

how did you create the ocker image (what was your 'docker run' command)?
if you like, you can attach the result of 'docker inspect deviation_build' (but please look at the result to make sure there is no personal info in there)

PhracturedBlue replied the topic: Docker containers for building deviation

the hashes aren't personal. anything with your real name or if you don't want your computer userid exposed would be things to look out for.

The errors you see don't make much sense. I wonder if this is a cr/lf issue (the scripts have a '^M' when you downloaded onto windows and in unix that messes up the execution). can you press the 'shell' button and try to execute:
/usr/bin/env perl
and
/usr/bin/env python

and make sure both give you an interactive prompt?
(you can usually use CTRL-D to exit the interactive prompt you get)

I'll try to test it on Windows when I get home. I hadn't tested using a mounted get repo previously

PhracturedBlue replied the topic: Docker containers for building deviation

I'm pretty sure it is simply that when you use git on windows, it adds CRLF characters to the end of the lines. Bash will not execute a script with CRLF endings. fixing it in the image is non-trivial. It may be easiest to just require developers to set the core.autocrlf setting to false. Also, there appears to be .gitattributes which may allow crlf configuration on a per file basis. I'll play with it and see if I can figure out a solution.

PhracturedBlue replied the topic: Docker containers for building deviation

Hmm...it isn't straight forward, because the container has no knowledge of the outer world. But the mounted filesystem preserves its attributes (which includes the directory owner uid). So we know who owned the directory initially, and could either try to create a user with the same uid. Maybe docker offers a better solution, I'll look into it.

I figured linux emulators wouldn't be too common so I didn't include them, but I could add support to auto-setup the build env quite eaisly.

TheSFReader replied the topic: Docker containers for building deviation

Hi,
Just to let you know, I've tried and "Dos2Unix" all files before launching a build and as PB thought, it built correctly. So now it leaves us to find which ones need to be either fixed, or specifically stored/used with "unix" line ending forced.

(Beginning to converge, utils and src/libopencm3 directories for now) (but not sufficient)

HappyHarry replied the topic: Docker containers for building deviation

i just tested building a container using a local git clone and it fails when building portaudio, well it builds it ok but something falls over when it's doing install-recursive, building a normal container works perfectly, and building a normal container and a container with a local git clone works fine on linux. here's the error

------------------------------------------------------------
PortAudio was successfully installed.
On some systems (e.g. Linux) you should run 'ldconfig' now
to make the shared object available. You may also need to
modify your LD_LIBRARY_PATH environment variable to include
the directory /root/portaudio-w32/lib
------------------------------------------------------------
make install-recursive
make[1]: Entering directory `/root/src/portaudio'
if test -n "" ; then for dir in ""; do make -C $dir install; done ; fi
make[1]: Leaving directory `/root/src/portaudio'
: No such file or directory
make[1]: *** [include/libopencm3/efm32/efm32g/irq.json.cleanhdr] Error 127
make: *** [distclean] Error 2
phil@Anubis-Desk MINGW64 ~

This should be the last time I need to update the docker image, I hope.

The big change here is that the build process will no longer run as 'root' but instead as a user called 'docker' This user should have the same userid/groupid as the user who owns the git repository. This should make things work much more smoothly when using a mounted git repo on Linux/Mac (though Mac is still untested). I did a bunch of experimentation with Windows builds too, and they all work for me now, so I'd like any feedback on that as well. I also included the gcc cross compiler in the image since it seems to take a long time to download for me, and I was sic of constantly re-fetching it. I left the windows libs as fetch on demand for now since they don't take as long, and many users may never need to build them.

Just installed the new image. Getting the errors below on Ubuntu with both the build button and running make from the command line. The git and releases trees show up as owned by docker:docker and most file permissions are 775. Maybe I have something non-standard somewhere.

I am betting that some file/directory has corrupted permission (possibly from using docker previously on your tree). you could also just try the following form inside docker (or outside docker using the proper path). Be REALLY careful with that rm -rf