integration tests using cps files pointing to libraries installed in ubuntu 22 #70
Comments
|
To post an update on what I've been doing. I created a tool to generate CPS files from PC files. You can find that here. https://github.com/tylerjw/cps-deps/tree/main Also, https://github.com/tylerjw/ubuntu-jammy-cps now includes a Dockerfile that'll generate cps files and a ton more files. |
Closed
|
I like this! And honestly the ability to convert a pc file into CPS sounds in-scope for cps-config as well |
lunacd
added a commit
to lunacd/cps-config
that referenced
this issue
Jun 23, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in cps-org#84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and cps-org#84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in cps-org#70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
lunacd
added a commit
to lunacd/cps-config
that referenced
this issue
Jun 26, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in cps-org#84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and cps-org#84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in cps-org#70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
lunacd
added a commit
to lunacd/cps-config
that referenced
this issue
Jun 26, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in cps-org#84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and cps-org#84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in cps-org#70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
lunacd
added a commit
to lunacd/cps-config
that referenced
this issue
Jun 26, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in cps-org#84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and cps-org#84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in cps-org#70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
bretbrownjr
pushed a commit
that referenced
this issue
Jul 8, 2024
## Main Change pkg-config compatibility is moved to a subcommand called `cps-config pkg-config`. As elaborated in #84, this would make it easier for users to adopt cps-config by aliasing `pkg-config` to `cps-config pkg-config`. This also makes it easier for contributors to test compatbility with pkg-config, and give more freedom in designing cps-specific interfaces. ## Other changes To make the above change, some additional changes are made: 1. The current top-level options are moved into `cps-config flags`, i.e. they are for generating linker and compiler flags for a package. My original intention is to not change the current interface at all, but CLI11 really don't like global options that are not propagated down to subcomands. Obviously, some options, like `--modversion`, doesn't sound like it belongs. And some other options, like `errors-to-stdout`, seems more appropriate as a global option. Those issues are currently ignored in this patch because I want to have a minimal set of changes that get the codebase into a semi-coherent state. We could have more in-depth discussions on specific interface designs as a separate issues and PR. But on a really high level, the future interface could look something like this: - pkg-config: pkg-config compatibility mode - pkgconf: pkgconf compatibility mode - flags: generate flags (but with cps-specific information like components) - list: list avaiable packages. This could even support globbing and this could be used as search as well. - search: maybe an alias to list - graph: graph-based operations like the ones pkgconf has but leveraging cps-specific data - info: print info for a package, like version, etc. - anything else we want 2. The current integration test suite is named as "pkg-config compatibility" but has since drifted away to include cps-specific behavior like components. The current test cases are renamed to `cps-config.toml` and a new `pkg-config-compat.toml` is created to test compatibility with pkg-config. 3. Currently, the example cps files are housed in `tests/cases`. The directory name seems more appropriate for test cases encoded in toml files. The example cps files are moved to `tests/cps-files`. ## Rationale See above and #84. ## Future work This change would make it much easier to have smoke tests for compatibility, as mentioned in #70. We could set up a test harness that installs all pc files available in ubuntu and transform them into cps files. Then it could randomly select a combination of supported pkg-config flags and avaiable libraries to make sure that `pkg-config` and `cps-config pkg-config` do the same thing. Obviously this would be too heavy weight to fit in CI and test suites. We should selectively implement found issues as test cases. Further, this could be used as our metric of "are we pkg-config compatible yet".
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: