This repository has been archived by the owner on Jun 14, 2018. It is now read-only.
Build project from top-level CMakeLists.txt #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We're going to add a top-level CMakeLists.txt, so whenever we use the top-level one the CMAKE_SOURCE_DIR variable is the top-level of the source tree. Subprojects such as libinsane and libinsane-gobject won't find their respective CMake includes because they're located one level deeper. Signed-off-by: aszlig <[email protected]>
This also adds the corresponding LDFLAGS and CFLAGS to the test targets and will only compile the tests if pkg-config was able to locate CUnit. Signed-off-by: aszlig <[email protected]>
This is only in preparation to the transition to having one CMakeLists.txt to build the base library and it's GLIB equivalents. The GLIB bindings are only built if CMake was able to locate it. Signed-off-by: aszlig <[email protected]>
The CMakeLists.txt in libinsane-gobject relies heavily on a specific directory structure and also uses a few workarounds that reference relative paths that might not be there when using our new top-level CMakeLists.txt. However, I've added a few workarounds as well, because right now we want to still support the Makefile that resides in the top-level until the buildbot scripts were adjusted so that they build from the top-level CMakeLists.txt. So for now this links the gobject bindings statically against libinsane, which we don't want to necessarily have in the long term (only optional at least). Signed-off-by: aszlig <[email protected]>
|
https://origami.openpaper.work/#/builders/2/builds/461 << build broken :/ |
Checking whether CMAKE_CURRENT_SOURCE_DIR equals CMAKE_SOURCE_DIR seems to be not very reliable, so let's actually set a variable in the top-level CMakeLists.txt which we can check in the individial projects. Signed-off-by: aszlig <[email protected]>
|
@jflesch: Fixed. |
|
https://origami.openpaper.work/#/builders/2/builds/464 : OK By the way, would it possible to make the root Makefile use this new CMakeLists.txt ? I think it would be the easiest way to make that this new CMakeLists.txt is actually maintained. |
|
@jflesch: Why not move completely to CMake and delete it? |
|
We can. I would have to update a little the scripts of the buildbot to generate the Makefile from the root CMakelists.txt, but that's no big deal. To minimize the changes in the buildbot scripts, I would just need the "standard" make targets that I use in all the other OpenPaper.work repositories:
Optionally, I also usually add:
|
GerHobbelt
pushed a commit
to GerHobbelt/libinsane
that referenced
this pull request
Sep 13, 2023
Reduce requests to underlying API Closes openpaperwork#1 See merge request World/OpenPaperwork/libinsane!6
GerHobbelt
pushed a commit
to GerHobbelt/libinsane
that referenced
this pull request
Sep 13, 2023
Libinsane: normalizers/source_nodes: set the source as soon as options are requested Closes openpaperwork#1 See merge request World/OpenPaperwork/libinsane!14
GerHobbelt
pushed a commit
to GerHobbelt/libinsane
that referenced
this pull request
Sep 13, 2023
…_descriptor() before sane_control_option(). When using the backend 'net', if we got a SANE_INFO_RELOAD_OPTIONS, we must first call sane_get_option_descriptor() before sane_control_option() even if we just want to use sane_control_option() to get the number of options. --> we make unused call here just to make backend 'net' reloads the options. This change make the workaround 'set_opt_late' useless --> removed. Fixes openpaperwork#1 Signed-off-by: Jerome Flesch <[email protected]>
GerHobbelt
pushed a commit
to GerHobbelt/libinsane
that referenced
this pull request
Sep 13, 2023
Sane: backend 'net': item->get_options(): always call... Closes openpaperwork#1 See merge request World/OpenPaperwork/libinsane!29
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should (hopefully, haven't tested) be backwards-compatible (especially for the buildbot-scripts) with the current top-level
Makefileand it introduces just a newCMakeLists.txtat the top-level plus adds a few more fixes that might come up in the future once distros are picking uplibinsane.The idea is to switch to the top-level
CMakeLists.txtfor the buildbot scripts and then unify everything into one CMake project, so that there is only the target for the actual library and glib. This should also get rid of a few hacks that have been made to for example referencelibinsanefromlibinsane-gobject.In the long term I guess it would also make sense to flatten the tree a bit, so there is only
srcfor the actual library andglibfor the GLIB bindings.