sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2022-02-16T15:34:59Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2256MacOS sysroot path is to specific, highly dependent on Xcode version2022-02-16T15:34:59ZHans-Nikolai ViessmannMacOS sysroot path is to specific, highly dependent on Xcode versionWhen compiling sac2c on MacOS, we append to `CCFLAGS` the `-isysroot` flag to the CMake variable [`CMAKE_OSX_SYSROOT`](https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_SYSROOT.html). This is needed so that when using sac2c we are a...When compiling sac2c on MacOS, we append to `CCFLAGS` the `-isysroot` flag to the CMake variable [`CMAKE_OSX_SYSROOT`](https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_SYSROOT.html). This is needed so that when using sac2c we are able to find C-libraries and other system libraries. We store `CCFLAGS` in the sac2crc files.
It is not clear to me, but for whatever reason the `CMAKE_OSX_SYSROOT` variable resolves to a path which is Xcode version specific, e.g. `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk`. This can cause problems whenever a newer version of Xcode is installed. MacOS PKG files have no notion of inter-dependency --- it is not a package manager as such.
Furthermore, if there are multiple versions of Xcode on the system, then we are totally doomed. This was experienced in Stdlib [PR 44](https://github.com/SacBase/Stdlib/pull/44).
It is not clear to me how best to resolve this, here are a few idea:
- there seems to be a generic sysroot path, of the form `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk`, but its not clear to me if this is dependable enough to rely on it.
- another is to poll for it when calling sac2c, using `xcode-select --print-path` or similar.
- as this path is encoded in the sac2crc files, we just need to update this. This could be possible as part of the [CPack productbuild process](https://cmake.org/cmake/help/git-stage/cpack_gen/productbuild.html) using the `CPACK_POSTFLIGHT_<COMP>_SCRIPT` variable to set a script which looks for the _correct_ path, and updates the sac2crc files **during** install.Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2225extend masterrun to build sac2c with/without various features2019-09-26T13:18:39ZHans-Nikolai Viessmannextend masterrun to build sac2c with/without various featuresThis issue was spawned from the MR !43 which made it evident that we need to extend the masterrun to build `sac2c` with or without various combinations of features. This should hopefully more quickly reveal problems like the one solved b...This issue was spawned from the MR !43 which made it evident that we need to extend the masterrun to build `sac2c` with or without various combinations of features. This should hopefully more quickly reveal problems like the one solved by the MR.
It is unclear though what the best way of doing this is; either we extend `.gitlab-ci.yml` to build sac2c with different feature flags, or we run a few more docker images with various installs. Are there other possibilities?https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2219Scheduled weekly packages should have different name to distinguish them.2019-02-08T14:57:32ZHans-Nikolai ViessmannScheduled weekly packages should have different name to distinguish them.Currently we jut use the default name given by CPack. We can override this with the `CPACK_PACKAGE_FILE_NAME` variable, making the weekly packages distinguishable from normal releasee packages.Currently we jut use the default name given by CPack. We can override this with the `CPACK_PACKAGE_FILE_NAME` variable, making the weekly packages distinguishable from normal releasee packages.Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2238sac2c/stdlib package dependendencies don't overlap2018-11-23T22:18:23ZHans-Nikolai Viessmannsac2c/stdlib package dependendencies don't overlapIt was pointed out by @Cybersmith that the weekly packages don't have overlapping dependencies... meaning that when we install sac2c, we can't install the stdlib package...
The issues seems to be that the sac2c packages install sac2c as...It was pointed out by @Cybersmith that the weekly packages don't have overlapping dependencies... meaning that when we install sac2c, we can't install the stdlib package...
The issues seems to be that the sac2c packages install sac2c as `sac-compiler-1.3.2-MijasCosta-<# CHANGES>-<COMMIT>` but the stdlib packages is looking for `sac-compiler-1.3.2-MijasCosta-<# CHANGES>` (or something to that effect). Something is configured in the stdlib cmakefiles...Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2232GTESTs CMake configuration error2018-09-29T11:06:49ZHans-Nikolai ViessmannGTESTs CMake configuration errorWhen running CMake with `-DFUNCTESTS=OFF`, we get the following error message:
```
$ cmake -DFUNCTESTS=OFF ..
... omitted content ...
CMake Error at tests/CMakeLists.txt:11 (ADD_TEST):
ADD_TEST given test NAME "test-test-condfun-nos...When running CMake with `-DFUNCTESTS=OFF`, we get the following error message:
```
$ cmake -DFUNCTESTS=OFF ..
... omitted content ...
CMake Error at tests/CMakeLists.txt:11 (ADD_TEST):
ADD_TEST given test NAME "test-test-condfun-nostdlib" which already exists
in this directory.
Call Stack (most recent call first):
tests/CMakeLists.txt:49 (REGISTER_TEST)
```
Does MR !67 fix this issue at all?Artem ShinkarovArtem Shinkarovhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2220Need more distinct package file names2017-12-13T15:07:23ZHans-Nikolai ViessmannNeed more distinct package file namesAfter merge requests like !35, it has become clear that the package generation can cause unintended overwrites of existing package blobs on the release server. A possible solution would be to append a timestamp to the name, or create a n...After merge requests like !35, it has become clear that the package generation can cause unintended overwrites of existing package blobs on the release server. A possible solution would be to append a timestamp to the name, or create a new directory with the timestamp as its name.