Hi,

I'm trying to create/install a package from a GitHub repo (that I do not own). The repo already uses CMake as its build system, so that's a positive start at least.

However, it seems the repo also uses git submodules, and therefore expects to have been cloned using the --recursive flag so that its submodule dependencies are also cloned.

Is there any way of telling cget to do a full recursive clone of the repo, instead of (I believe) downloading the zip archive (which does not include any submodules)?

If not, do you have any suggestions on an alternative approach I could try?

Thanks!

Hi,

Would it be possible to consider adding --debug and --release flags to the build command, similar to those that already exist for install?

It's of course possible that I'm trying to use cget wrong, but my use-case is that I'm using cget to build my local project (in addition to installing and building its dependencies), and I'd like to optionally build it with debug symbols occasionally.

I was a bit surprised there was no --debug flag for the build command, so as a workaround I tried passing in a custom --define CMAKE_BUILD_TYPE=Debug to the command instead, however that also didn't work due to the issue I've detailed in #55.

So for now I've resorted to simply adding a set(CMAKE_BUILD_TYPE Debug) line to my local package's CMakeLists.txt file. However this is not ideal as I would prefer to be able to toggle it within the cget command line rather than having to edit a file.

Thanks!

First of all, awesome idea! It'd be nice if the requirements file allowed specifying cmake flags to pass onto the dependencies, e.g., -DCMAKE_CXX_FLAGS=..., etc.

Moving the cget directory after an install results in broken links which make the project unable to compile. This is a somewhat difficult to spot error for a first time user (maybe it's just me). Is there a way to avoid this by relative paths? Could be a nice feature for the project.

Has cget been tested with cmake v3.14.0? All of my cget installs fail with this version of cmake, but not with earlier versions like v3.5.1 and v3.8.1. The problem is that the cget/include directory is not being set as an include directory for the project being built.

Hi,

Given the following simple CMakeLists.txt with an added check that aborts if BUILD_TESTING is set:

$ cat CMakeLists.txt 

cmake_minimum_required(VERSION 3.12)
project(SimpleTest)

set(CMAKE_CXX_STANDARD 14)

if(BUILD_TESTING)
	message(FATAL_ERROR "BUILD_TESTING is set. Aborting.")
endif()

add_executable(SimpleTest main.cpp)

When building manually it works successfully:

$ mkdir build
$ cd build
$ cmake ..
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/gcc-7
-- Check for working C compiler: /usr/bin/gcc-7 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++-7
-- Check for working CXX compiler: /usr/bin/g++-7 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /SimpleTest/build
$
$ make
Scanning dependencies of target SimpleTest
[ 50%] Building CXX object CMakeFiles/SimpleTest.dir/main.cpp.o
[100%] Linking CXX executable SimpleTest
[100%] Built target SimpleTest

However, if building using cget build (or cget install), the BUILD_TESTING flag seems to somehow have been set, causing the command to abort:

$ cd ..
$ rm build -r
$ cget build
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/gcc-7
-- Check for working C compiler: /usr/bin/gcc-7 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++-7
-- Check for working CXX compiler: /usr/bin/g++-7 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:7 (message):
  BUILD_TESTING is set.  Aborting.


-- Configuring incomplete, errors occurred!
See also "/SimpleTest/cget/cget/build/_url_L2hvbWUvdGhvdWdodG9uL0RvY3VtZW50cy9Db2RpbmcvQ2dldFByb2plY3RzL1NpbXBsZVRlc3Q_/build/CMakeFiles/CMakeOutput.log".
Command failed: ['/home/linuxbrew/.linuxbrew/bin/cmake', '-DCMAKE_TOOLCHAIN_FILE=/SimpleTest/cget/cget/cget.cmake', u'/SimpleTest', '-DCGET_CMAKE_DIR=/.local/lib/python2.7/site-packages/cget/cmake', '-DCGET_CMAKE_ORIGINAL_SOURCE_FILE=/SimpleTest/__cget_original_cmake_file__.cmake', '-DBUILD_TESTING=On', '-DCMAKE_BUILD_TYPE=Release']
Failed to build package .
$ 

(It can also be clearly seen in the echo of the failed command above that -DBUILD_TESTING is explicitly being set in the command arguments being executed.)

Is there a way to configure this default? Or is it simply a bug?

(For the record, it currently makes it quite tricky to setup a project with optional tests.)

Thanks!

I'm trying to figure out a sane way to allow sys admins to install just the library dependencies of an executable into the build tree, link to the libs statically and then install just the executable into a system path. In this scenario the install prefix for the dependencies is different than the install prefix for the executable. The following does the trick but is a little verbose.

mkdir build
cd build
cget install --file ../requirements.txt --prefix .
cmake -DCMAKE_PREFIX_PATH=`pwd` ..
make
sudo make install # Installs executable to /usr/local

Is there a better way of doing this or are there any ideas on how cget could support this in the future?

Also, is setting CMAKE_PREFIX_PATH to the cget prefix path the recommended way of using cget with IDEs like CLion?

I get the following error:

$ pip install cget
Collecting cget
  Could not find a version that satisfies the requirement cget (from versions: )
No matching distribution found for cget

cget uses a unique ID for every package download. This results in the file path being different for each build of the same package, resulting in a cache miss in ccache when cget is asked to build a package with ccache enabled.

This PR replaces the UUID with a hash of the package source for reproducibility.

When installing packages, the --debug command-line flag was not always obeyed. It always worked correctly for "cget install --debug <pkg_name>", and also always worked correctly when installing packages as part of "cget build --debug". But for "cget install --debug" using the requirements.txt file, the --debug command-line flag was not used. This commit fixes it.

I am currently using cget 0.1.7 and cmake 3.5.1 on ubuntu 16.04 lts

I have tried to install libffi v3.2.1 via requirements.txt file, with the following line libffi,libffi/[email protected] --cmake autotools, but the automatically generated CMakeLists.txt ends execution with the error shown below. Using the command cget install libffi,libffi/[email protected] --cmake autotools results in the same error.

Downloading https://github.com/libffi/libffi/archive/v3.2.1.tar.gz
  [######################################################################]  100%
Extracting archive /home/igor/foo/cget/cget/build/tmp-98ba454730bf43a3bc7acf6ed231570e/v3.2.1.tar.gz ...
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
No such file or directory
CMake Error at CMakeLists.txt:33 (message):
  Process failed:
  COMMAND;/usr/bin/cmake;-E;env;PATH=/home/igor/foo/cget/bin:/usr/local/bin:/usr/bin://bin:/usr/bin:/home/igor/foo/cget/cget/pkg/libffi/install/bin:/home/igor/foo/cget/bin:/toolchain/mips-4.3-51/mips-4.3/bin:/toolchain/arm-2014.05/bin:/usr/lib/ccache:/home/igor/bin:/usr/local/bin:/toolchain/mips-4.3-51/mips-4.3/bin:/toolchain/arm-2014.05/bin:/usr/lib/ccache:/home/igor/bin:/usr/local/bin:/home/igor/.cargo/bin:/home/igor/.cargo/bin:/home/igor/bin:/home/igor/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin;PKG_CONFIG_PATH=/home/igor/foo/cget/lib/pkgconfig:/home/igor/foo/cget/lib64/pkgconfig:/home/igor/foo/cget/share/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/lib64/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig://lib/pkgconfig://lib64/pkgconfig://share/pkgconfig:/usr/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig:/home/igor/foo/cget/cget/pkg/libffi/install/lib/pkgconfig:/home/igor/foo/cget/cget/pkg/libffi/install/lib64/pkgconfig:/home/igor/foo/cget/cget/pkg/libffi/install/share/pkgconfig;CC=/usr/lib/ccache/cc;CXX=/usr/lib/ccache/c++;CFLAGS=-isystem
  /home/igor/foo/cget/include -isystem
  /home/igor/foo/cget/include;CXXFLAGS=-isystem
  /home/igor/foo/cget/include -isystem
  /home/igor/foo/cget/include;LDFLAGS=;/home/igor/foo/cget/cget/build/tmp-98ba454730bf43a3bc7acf6ed231570e/libffi-3.2.1/configure;--prefix=/home/igor/foo/cget/cget/pkg/libffi/install;WORKING_DIRECTORY;/home/igor/foo/cget/cget/build/tmp-98ba454730bf43a3bc7acf6ed231570e/build/build
Call Stack (most recent call first):
  CMakeLists.txt:147 (exec)


-- Configuring incomplete, errors occurred!
See also "/home/igor/foo/cget/cget/build/tmp-98ba454730bf43a3bc7acf6ed231570e/build/CMakeFiles/CMakeOutput.log".
Command failed: ['/usr/bin/cmake', '-DCMAKE_TOOLCHAIN_FILE=/home/igor/foo/cget/cget/cget.cmake', '-G', u'Ninja', '/home/igor/foo/cget/cget/build/tmp-98ba454730bf43a3bc7acf6ed231570e/libffi-3.2.1', '-DCGET_CMAKE_DIR=/usr/local/lib/python2.7/dist-packages/cget/cmake', '-DCGET_CMAKE_ORIGINAL_SOURCE_FILE=/home/igor/foo/cget/cget/build/tmp-98ba454730bf43a3bc7acf6ed231570e/libffi-3.2.1/__cget_original_cmake_file__.cmake', '-DBUILD_TESTING=Off', '-DCMAKE_BUILD_TYPE=Release', '-DCMAKE_INSTALL_PREFIX=/home/igor/foo/cget/cget/pkg/libffi/install']
Failed to build package libffi```

Patching CVE-2007-4559

Hi, we are security researchers from the Advanced Research Center at Trellix. We have began a campaign to patch a widespread bug named CVE-2007-4559. CVE-2007-4559 is a 15 year old bug in the Python tarfile package. By using extract() or extractall() on a tarfile object without sanitizing input, a maliciously crafted .tar file could perform a directory path traversal attack. We found at least one unsantized extractall() in your codebase and are providing a patch for you via pull request. The patch essentially checks to see if all tarfile members will be extracted safely and throws an exception otherwise. We encourage you to use this patch or your own solution to secure against CVE-2007-4559. Further technical information about the vulnerability can be found in this blog.

If you have further questions you may contact us through this projects lead researcher Kasimir Schulz.

For reasons I have not entirely traced, URLopener (and thus FancyURLopener) does not work with some proxies. I can see that instead of setting up a tunnel with a CONNECT request, it makes a GET request to the proxy, which in my case induces a 502-bad-gateway response. Even though it recognises the proxy settings, it doesn't quite do the right thing.

However, urlopen uses ProxyHandler to accommodate the situation, and does work through this troublesome proxy. urllib.request.urlretrieve has the same interface as URLopener.retrieve, and seems like a drop-in replacement. I added a try/except around the urlretrieve to get the BuildError for responses of 400 or greater, since there is no longer a custom http_error_default or a good place to hang it.

This change addresses my internal build problem and probably also issues #52 and #77. Plus, no more deprecation warnings.

Bumps numpy from 1.20.3 to 1.22.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Currently issuing the following command fails silently:

cget install -f /path/does/not/exist

completes successfully.

This should be an error with the exit code reflecting an error