is_visual = "Visual Studio" in hive_disk_image.settings.cmake.generator
build_config = '-C Debug' if is_visual and '-C' not in parameters else ''

So XCode is missing configuration to run tests. Reported by http://forum.biicode.com/t/biicode-compatibility-with-xcode/408

Currently, configuring some library/block to use C++11/14 is a bit complex. There are several options:

1-. Native use of CMake. It can require some conditionals for MultiOS

IF(UNIX)
    IF(CLANG)
        TARGET_COMPILE_OPTIONS(${BII_BLOCK_TARGET} INTERFACE -std=c++11)
....

2-. Use an existing CMake macro, possibly one existing in biicode and retrieved as dependency:

INCLUDE(biicode/cmake/tools)
ACTIVATE_CPP11(INTERFACE ${BII_BLOCK_TARGET})

This one requires one bii find or [requirements] to be written.

PROPOSAL:

From my point of view, it is still a bit complex, so I propose a high level definition, in biicode.conf, something like:

[cpp-std]
     c++11 PUBLIC   # or c++11 libstdc++...

That would be translated to a cmake variable, and biicode, checking that variable would automatically call something in the line of ACTIVATE_CPP11. Surely we have to check for CMake compile features as solution for this, instead of bare compile options.

Pros:

• Much simpler approach
• Easily deals with propagating usage to consumers
• Might be able to deal with the problem of collisions
• Totally optional, the user can still use the other approaches

Cons:

• It wires the config to the internal ACTIVATE_CPP11 implementation, that might change with new versions of biicode, so changes, improvements, could break something.

OS: Ubuntu 14.10
Biicode Client 3.3

Steps to reproduce:

$ bii init -l clion testproject
$ cd testproject
$ bii open messmer/blockstore
$ bii configure

Output:

INFO: Processing changes...
Running: "cmake"  -G "Unix Makefiles" -Wno-dev  ..
-- The C compiler identification is GNU 4.9.1
-- The CXX compiler identification is GNU 4.9.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done

                BLOCK: google/gtest 
-----------------------------------------------------------
-- Found PythonInterp: /usr/bin/python (found version "2.7.8") 
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
+ LIB: google_gtest

                BLOCK: cryptopp/cryptopp 
-----------------------------------------------------------
CALLING INIT_BIICODE_BLOCK IS NO LONGER NECESSARY
+ LIB: cryptopp_cryptopp
-- Writing default cmake_dummy.cpp for building library
BUILDING cryptopp_cryptopp

                BLOCK: google/gmock 
-----------------------------------------------------------
CALLING INIT_BIICODE_BLOCK IS NO LONGER NECESSARY
+ LIB: google_gmock
-- Writing default cmake_dummy.cpp for building library
CMake Error at deps/google/gmock/CMakeLists.txt:33 (MESSAGE):
  GTest dependency isn't in your project/deps folder


-- Configuring incomplete, errors occurred!
See also ".../testproject/build/CMakeFiles/CMakeOutput.log".
See also ".../testproject/build/CMakeFiles/CMakeError.log".
ERROR: CMake failed

CMakeError.log:

File .../testproject/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <pthread.h>

int main(int argc, char** argv)
{
  (void)argv;
#ifndef pthread_create
  return ((int*)(&pthread_create))[argc];
#else
  (void)argc;
  return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: .../testproject/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTryCompileExec3856153446/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec3856153446.dir/build.make CMakeFiles/cmTryCompileExec3856153446.dir/build
make[1]: Entering directory '.../testproject/build/CMakeFiles/CMakeTmp'
/home/.../.biicode_env/cmake-3.0.2-Linux-64/bin/cmake -E cmake_progress_report .../testproject/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec3856153446.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create   -o CMakeFiles/cmTryCompileExec3856153446.dir/CheckFunctionExists.c.o   -c /home/.../.biicode_env/cmake-3.0.2-Linux-64/share/cmake-3.0/Modules/CheckFunctionExists.c
Linking C executable cmTryCompileExec3856153446
/home/.../.biicode_env/cmake-3.0.2-Linux-64/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec3856153446.dir/link.txt --verbose=1
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create    CMakeFiles/cmTryCompileExec3856153446.dir/CheckFunctionExists.c.o  -o cmTryCompileExec3856153446 -rdynamic -lpthreads 
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
CMakeFiles/cmTryCompileExec3856153446.dir/build.make:88: recipe for target 'cmTryCompileExec3856153446' failed
make[1]: Leaving directory '.../testproject/build/CMakeFiles/CMakeTmp'
make[1]: *** [cmTryCompileExec3856153446] Error 1
Makefile:118: recipe for target 'cmTryCompileExec3856153446/fast' failed
make: *** [cmTryCompileExec3856153446/fast] Error 2

It works fine when using standard or minimal project layout.

This is probably an upstream bug in CMake, and I've reported it as such: http://public.kitware.com/Bug/view.php?id=15682

Opening the bug here for reference in case anyone else found the same issue when using -G Ninja with bii cpp:configure

One of the problems of biicode is the low number of libraries hosted on biicode. However, I think many C++ libraries (e.g. header-only libraries without further dependencies or libraries that are built using cmake) could be biicode compatible without changing anything (also without adding a biicode.conf file).

We could quickly grow the number of available biicode dependencies if we support depending on libraries that are not hosted on biicode, but somewhere else (github, sourceforge, ...). These projects wouldn't even need a biicode.conf in this case.

I'm not sure on the developer workflow for this, some options are:

1. using a virtual "github" account on biicode

   #include <github/username/repository/path/file.h>
   

2. Adding such repositories to a section in biicode.conf

   [external_dependencies]
   myrepo: [email protected]:username/repository
   

Ideally, the solution would support generic protocols (download project via git, zip over http, ...) as opposed to certain providers (github, sourceforge, ...). Then we could also use it for projects hosted on providers that are used less often (bitbucket, google code, ...)

OS: Ubuntu 14.10
Biicode: 3.0

Steps to reproduce:

$ git clone [email protected]:smessmer/cryfs.git
$ cd cryfs
$ bii init -l
$ bii build -- -j5

Then, without changing any files, directly call

$ bii build -- -j5

It runs the whole configure step again before it notices that actually nothing changed. For projects with some dependencies, this happening with each compiler call is a lot of lost time.

Especially in a project with multiple open blocks (old project layout), this configure step takes quite a while, because configuring an open block takes longer than configuring a closed block.

The purpose of this ticket is to describe some user experience hurdles on windows for a first time user.

Preconditions: I had CMake 3.2 and Visual Studio 2013 installed.

• Download bii-win_3_0.exe
• Install, select "Add to system's path" (less problems with continuous integration service; no idea why one would recommend current user...), uncheck "View ReadMe" (online docs are open anyway...)
• Press Windows+R, type cmd, press Enter
• Follow Getting Started

Problems:

• bii setup:cpp does not detect Visual Studio
• bii build does not automatically fall back to NMake/Visual Studio if MinGW isn't installed

I suggest to use Visual C++ as default on Windows, as its part of the Windows SDK, which is "free" and superior to MinGW in many aspects (compatibility, 64bit, Microsoft language extensions, ...)

As for configuration: I think it'll be nice to have an interactive list to choose from, e.g.:

Choose one of the following generators:
  1. NMake
  2. Visual Studio 2013
  3. Visual Studio 2015
  4. Sublime Text
<If generator does not support multiple targets>
Choose one of the following targets:
  1. Windows 32bit
  2. Windows 64bit
  3. Emscripten
  4. Android
<IDE opens>

Thanks for making such a great tool. Keep up the good work! 👍

When including a header file from the same block show a more detailed warning pointing to the code line where the broken include is

http://forum.biicode.com/t/warning-on-absolute-include-paths-into-same-block/389

OS: Ubuntu 14.10
Biicode: 3.0

Steps to reproduce:

$ git clone [email protected]:smessmer/cryfs.git
$ cd cryfs
$ bii init -l
$ bii cpp:configure -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug

Then try to import the project into eclipse (Version: Luna Service Release 1 (4.4.1) Build id: 20140925-1800) under File -> Import -> Existing Projects Into Workspace

I get the following error:

Error processing changed links in project description file.
  Cannot create a link to '[homedir]/cryfs/bii' because it overlaps the location of the project that contains the linked resource.

OS: Ubuntu 14.10
Biicode 3.0

Steps to reproduce:

$ mkdir cryfs
$ cd cryfs
$ bii init
$ bii open messmer/cryfs
$ bii cpp:configure -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug

Import project into eclipse: File -> Import -> Existing Projects Into Workspace.
There now is a "blocks" folder in the eclipse project containing the blocks

$ bii build -- -j5

In eclipse: Right click on the project and select "Refresh". The "blocks" folder is gone.

$ bii cpp:configure -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug

In eclipse: Refresh again. The "blocks" folder is there again.

Possibly related #22: when calling build, it re-configures the whole project.

Reported in: http://forum.biicode.com/t/bii-configure-reports-cmake-not-found-but-cmake-is-installed/392/3 by @kirkshoop

It seems that .bat file has some problem for being launched with the current implementation.

@Manu343726 also uses chocolatey packages on win, could you please have a look?.

(see http://forum.biicode.com/t/show-warnings-only-for-open-blocks/334 )

I'd like to use warning flags like "-Wall -Wextra -Weffc++" on my code, but using

TARGET_COMPILE_OPTIONS(${BII_BLOCK_TARGET} INTERFACE -Wall -Wextra -Weffc++)

shows a lot of warnings for the blocks I'm including (e.g. boost).

Reasoning
I generally assume the libraries I use are working, but might not be written using good C++ style. Some libraries might be written well, but still throw warnings on -Weffc++, because they use certain constructs for performance (e.g. boost often doesn't have virtual destructors on inherited classes).

As a developer using an arbitrary library, it is not necessarily my task to remove the warnings from their code (which might sometimes not be possible like in the boost example above), but I'd like to use the warnings mechanism to be notified of style issues in my own code. Warnings in code written by others just clutters the output and makes it harder for me to find the issues in my own code.

Many languages (e.g. Java, Scala, ...) only show you warnings in your own code and I think that this generally is the better approach. But because of the C++ header inclusion mechanism, compilers can't easily distinguish whether you're including a header you've written yourself or a header from a library.
They actually can distinguish whether you're including a system header, and in this case, they also hide the warnings from there. But they can't easily distinguish 3rd party library headers from your own headers (the 3rd party library might just be in some subfolder of your project for example).

Different to plain compilers, biicode is in a position to easily decide whether a header is a 3rd party header or not (open blocks are own code, closed blocks 3rd party). So biicode might have the chance here to be better than previous systems.

Since this is a behavior C++ programmers might not be used to, an opt-in or opt-out could be offered. I'll definitely opt-in, because I think it is much better behavior.

Possible implementation
I've read that including other libraries as system libraries makes gcc ignore warnings for these library headers. This could for example be done with

include_directories(SYSTEM "${LIB_DIR}/Include")

Is it possible to include closed blocks this way and therefore make gcc only show warnings for open blocks?

On OS X El Capitan, here's what I'm getting when trying to install through the installer:

A dialog pops up and says:

This package is incompatible with this version of OS X and may fail to install.

Installing this package may damage your system, and the installation may fail. To stop the program and the installation, click “Cancel Installation”.

If "Install anyway" is chosen, the installer returns an error at the summary step:

Through Homebrew Cask:

==> brew cask install Caskroom/cask/biicode                                              
==> Downloading https://s3.amazonaws.com/biibinaries/release/3.3/bii-macos-64_3_3.pkg    
Already downloaded: /Library/Caches/Homebrew/biicode-3.3.pkg                             
==> Running installer for biicode; your password may be necessary.                       
==> Package installers may write to any location; options such as --appdir are ignored.  
Password:                                                                                
==> installer: Package name is Biicode                                                   
==> installer: Installing at base path /                                                 
==> installer: The install failed (The Installer encountered an error that caused the ins
Error: Command failed to execute!                                                        

==> Failed command:                                                                      
["/usr/bin/sudo", "-E", "--", "/usr/sbin/installer", "-pkg", "#<Pathname:/opt/homebrew-ca
sk/Caskroom/biicode/3.3/bii-macos-64_3_3.pkg>", "-target", "/"]                          

==> Output of failed command:                                                            
installer: Package name is Biicode                                                       
installer: Installing at base path /                                                     
installer: The install failed (The Installer encountered an error that caused the install
ation to fail. Contact the software manufacturer for assistance.)                        


==> Exit status of failed command:                                                       
#<Process::Status: pid 33082 exit 1>

• Add a toolchain for android
• android:settings command to help configure paths to android tools
• ...

(see http://forum.biicode.com/t/passing-through-cmake-parameters-for-bii-cpp-test/327 )

For builds, it is possible to run

bii cpp:build -- -j4

to achieve a parallel build.

However, when using it for tests, the -j4 parameter isn't forwarded to cmake:

bii cpp:test -- -j4  // -j4 is ignored here

It is possible to run

 bii cpp:build --target check -- -j4

instead, but it would be more beautiful if "bii cpp:test" would pass through the parameters to cmake like "bii cpp:build" does.

While init workspace, please add default .gitignore file
or there be many files should not be add into git tracks

Choose what our terms will be and write them in a CONTRIBUTING.md file for client and common.

Examples:

https://github.com/libuv/libuv/blob/v1.x/CONTRIBUTING.md

Extract squash and rebase stuff:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md