CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=0.9.4 2016-11-03T09:31:58+00:00 2016-11-03T09:31:58+00:00 stijn stijn@ignitron.net 2016-11-01T09:24:22+00:00 urn:sha1:0b9ed550267ca0efba094d14c250f268d744818d 2016-06-25T20:49:45+00:00 stijn stijn@ignitron.net 2016-06-23T07:55:28+00:00 urn:sha1:4b9046328dd9cc5905bc7c971eaa03248f0f0396 Fixes linker errors since [ad229477] and adds the umachine module so tests pass. 2016-06-15T22:42:48+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-06-15T22:40:31+00:00 urn:sha1:f469c764428230363a2b22fedf303d86eea82853 It has more usages than just qstr extraction, for example, embedding (where people don't care about efficient predefined qstrs). 2016-05-08T10:07:57+00:00 stijn stijn@ignitron.net 2016-04-27T14:00:41+00:00 urn:sha1:87106d025bcbb7508e9be68efa57e800778365ab This will launch about as many compiler instances as there are logical processors on a machine, and as such significantly speeds up compilation. 2016-04-25T21:34:24+00:00 stijn stinos@zoho.com 2016-04-23T16:55:14+00:00 urn:sha1:29c8c8aecb3409e57a43256f8fe5cb25de1e9856 Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines). 2016-04-16T12:19:15+00:00 stijn stijn@ignitron.net 2016-03-15T09:22:34+00:00 urn:sha1:9a627e8881c1b5d8fad9f1a563b5af23716e1b55 Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow. 2016-01-26T19:38:59+00:00 Damien George damien.p.george@gmail.com 2016-01-26T19:38:59+00:00 urn:sha1:e713222fabe1c3987364870ed592db38529bc4a3 2015-12-18T20:10:51+00:00 stijn stijn@ignitron.net 2015-12-16T11:25:48+00:00 urn:sha1:c5f52b845b62e1562ca48943f1bab03a8da99059 This fixes the build after adding directory iteration in d874702 2015-12-14T22:13:21+00:00 stijn stinos@zoho.com 2015-12-14T20:12:52+00:00 urn:sha1:951fc7e993ae8069444c5cffbc889a6f305a8455 2015-12-11T21:42:30+00:00 stijn stijn@ignitron.net 2015-11-12T08:42:12+00:00 urn:sha1:967ceba5b7fc56f7642947b2c48199a4d9db0d4a This allows multiple versions (e.g. Debug/Release, x86/x64) of micropython.exe to co-exist instead and also solves potential problems where msbuild does not completely rebuild the output and/or pdb files when switching between builds, which in turn can cause linker errors in dependent projects. By default exe/map/... files go in windows/build/$(Configuration)$(Platform) After each build micropython.exe is still copied from the above directory to the windows directory though, as that is consistent with the other ports and the test runner by default uses that location as well. Also rename env.props -> path.props which is a clearer name, and add ample documentation in the affected build files. (also see discussion in #1538)