quiet / QuietModemKit

iOS framework for the Quiet Modem (data over sound)
BSD 3-Clause "New" or "Revised" License
451 stars 49 forks source link

Unable to build #6

Closed xzenon closed 7 years ago

xzenon commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

weidaxu1988 commented 7 years ago

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

brian-armstrong commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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