even when using the cache, the macos job on PR takes a lot of time, due
to the hardware limitations causing execution to take so much time. So
instead, we limit the macos job to the build to make sure it can
compile, and only run the tests for macos on push events
This has been generated using linalg tools, then put in their
appropriate locations. This is intended as a workaround since linalg
doesn't support tensors of custom types yet. Any conversion using this
added operation should be able to use the default operation from linalg
when it starts supporting tensor of custom types.
we don't want the version file to be included in the package to not
clash with version files of other subpackages, as it should be part of
the bigger concrete namespace package
Compiler tools such as CompilerEngine would now be imported from
concrete.compiler
Dialects would now be imported from concrete.lang.dialects
And anything related to concretelang can be imported directly from
concrete.lang
[----------] Global test environment tear-down
[==========] 6 tests from 1 test suite ran. (1402 ms total)
[ PASSED ] 6 tests.
YOU HAVE 3 DISABLED TESTS
2 tests are disabled because execution is fatal
This adds a new variable `CCACHE` to `Makefile` that specifies whether
CMake is instructed upon configuration of the project to use the
default, plain C++ compiler or ccache as a wrapper.
By default, ccache is not used. To override the default value and
force the use of ccache, the variable `CCACHE` must be set to `ON`,
e.g., using `make CCACHE=ON`.
Most of the targets in `Makefile` do not deped on files produced by
other targets and use target names solely for dependency
management. Make all such targets PHONY in order to avoid that they
are skipped accidentially when a file with the same name is present.
The Makefile target `python-bindings` invokes CMake with multiple
targets specified after the `--target` commandline option. However, as
per the CMake manpage, only one target may be specified at once.
This changes the single invocation of CMake to separate invocations
for each target.
Tested with CMake version 3.13.4.
The target `build` creates a build directory with the same name and
initializes through an invocation of CMake. Regardless of the success
or failure of the CMake invocation, all subsequent invocations of the
target do not invoke CMake anymore, as the target's prerequisites are
satisfied through the existence of the build directory created upon
the first invocation.
This patch changes the dependencies to the build directory with an
intermediate target that depends on a stamp file that is only created
when the first CMake invocation in the build directory succeeds.
- Docker image to build wheels for linux_x86_64 CPython 3.[8,9,10] with
GLIBC >= 2.24
- Specify which Python to use in Makefile
- Fix cmake build to handle when libpython isn't available (cmake>3.18)
