Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to build #6

Closed
xzenon opened this issue May 12, 2017 · 9 comments
Closed

Unable to build #6

xzenon opened this issue May 12, 2017 · 9 comments

Comments

@xzenon
Copy link

xzenon commented May 12, 2017

Hello! I'm trying to build framework using Carthage and unable to successfully do that.
Here is the output log : https://gist.github.com/xzenon/e342865614ae0d482ddc1a86947fc9be

Error message says:

libquiet requires libliquid but cannot find it

  fetch the devel branch using

      git clone https://github.com/quiet/liquid-dsp.git -b devel --single-branch

  and install it before continuing

I've fetched libliquid sources, compiled and installed it manually but still unable to compile QuietModem.

Would be great if you can advice something. Thanks!

@brian-armstrong
Copy link
Member

Hi @xzenon

Sorry to hear it isn't working. This error message is not especially helpful, so I apologize for that. QuietModemKit comes bundled with liquid-dsp and has its paths set to only use its own internal build for dependencies, so it wouldn't be able to use your host installation.

It looks like the relevant error is the line that says "CMake Error: The source directory ... does not appear to CMakeLists.txt". This is telling us that somehow the git submodule containing liquid doesnt seem to have CMake build. Can you look at the contents of Carthage/Checkouts/QuietModemKit/liquid-dsp and tell me if it's empty? Looking at the submodule in github, it does indeed contain that file, so it's rather perplexing how your checkout doesnt have it

@xzenon
Copy link
Author

xzenon commented May 15, 2017

Hi! Thanks for answer!
Checkouts/QuietModemKit/liquid-dsp is not empty and definitely contains CMakeLists.txt.

Here is the updated gist with the contents of CMakeError.log and CMakeOutput.log files - https://gist.github.com/xzenon/ab1c5bb6aaf85e0ac1e265db4a2ec044.

Are you able to build it for scratch without errors?

@weidaxu1988
Copy link

got the same problem too, @xzenon have you solve the problem?

@weidaxu1988
Copy link

problem solved! turns out that I didn't have cmake installed

@brian-armstrong
Copy link
Member

@xzenon Yes, a clean build worked for me just now. I made a brand new iOS project and added a Cartfile, put quiet in it, and successfully ran carthage update.

Looking at your errors, it looks like you got liquid to build this time - it's a different error from before? Did anything change that caused liquid to start building?

The new error is strange, it sounds like it's looking for x86_64 symbols in the iOS platform, which would be ARM only. Can you confirm if the directory /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform is present on your file system?

@brian-armstrong
Copy link
Member

@weidaxu1988 Glad to hear it. I've been meaning to make it more clear that cmake is required. Sorry you hit a snag there.

@xzenon
Copy link
Author

xzenon commented May 21, 2017

@brian-armstrong Yes, the directory is present.
But seems like something wrong on my system - I tried on other machine and successfully ran carthage update without problems.
Anyway thanks for your support!

Also have a question - could you please describe the purpose of QMFrameReceiver's methods:

- (NSData *)receive;
- (void)setBlocking:(long)seconds withNano:(long)nano;
- (void)setNonBlocking;

I've setup a test project and seems like QM works pretty fine for my purposes using "ultrasonic-experimental" profile. But I'd like to know how to properly use and shutdown receiver. When I call close it took several seconds to complete that operation. Am I doing something wrong?

@brian-armstrong
Copy link
Member

@xzenon

Glad you got it working! I'm still not sure what the cause of your build failure was, unfortunately

The set blocking/nonblocking methods are related to receiving. In nonblocking mode, the receive method returns immediately if there are no packets waiting in the receive queue. This might be handy if you're using it on the UI thread. Most applications will probably use it in blocking mode though, where it will wait until either the blocking timeout or until a packet is received

And I believe close does always take that long, unfortunately. I should look into shortening that time or making a more abrupt shutdown method. The reason it takes so long is that it waits for the soundcard receiver and internal queues to close, which do take a little while. Though, I'm not sure if it should actually take longer than a second or so. I may need to look into that more

@xzenon
Copy link
Author

xzenon commented May 22, 2017

@brian-armstrong Would be great to have quick shutdown method.
Anyway thanks for answers and great tool!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants