diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py index 510e6b852..08489337e 100644 --- a/admin/scons/Setup.py +++ b/admin/scons/Setup.py @@ -74,7 +74,7 @@ def defineBuildEnvironment(): env.Replace( CPPPATH =["#src"] # used to find includes, "#" means always absolute to build-root , CPPDEFINES=['LUMIERA_VERSION='+VERSION ] # note: it's a list to append further defines , CCFLAGS='-Wall -Wextra -Wformat-security' - , CXXFLAGS='-std=gnu++14 -Wno-enum-compare -Wno-noexcept-type' + , CXXFLAGS='-std=gnu++17 -Wno-enum-compare' , CFLAGS='-std=gnu99' ) env.Append(LINKFLAGS='-Wl,--no-undefined') # require every dependency is given on link, in the right order diff --git a/doc/technical/build/BuildDependencies.txt b/doc/technical/build/BuildDependencies.txt index de350c20d..db70c83f7 100644 --- a/doc/technical/build/BuildDependencies.txt +++ b/doc/technical/build/BuildDependencies.txt @@ -1,7 +1,7 @@ Build Dependencies ================== :Author: core-devs -:Date: 11/2015 +:Date: 2/2020 :toc: @@ -54,29 +54,32 @@ Languages and Tools * C / C++ - - a C99 / C++14 compatible compiler footnote:[in practice, we build using GCC and + - a C99 / C++17 compatible compiler footnote:[in practice, we build using GCC and occasionally we check using Clang] - - GCC *4.9* or Clang *3.5* should be fine footnote:[basically we try to use just the stock language. + - GCC *7* or Clang *6* should be fine footnote:[basically we try to use just the stock language. On rare occasions in the past, we _did_ use some GCC extensions, like `typeof()`, but we care for workarounds, in case this becomes a problem. Incidentally, `typeof()` is obsoleted by the new C++ standard, which provides `decltype()` for this purpose.]. * BOOST (listed below are the Debian package names) - - libboost-dev (at least *1.55*) + - libboost-dev (at least *1.67*) - libboost-program-options-dev - libboost-program-options-dev - libboost-filesystem-dev * Script languages - - Python (*2.7*) for build scripts + - Python (*2.x*) might still be handy for build scripts.footnote:[SCons supports both Python 2.x + and Python 3.x transparently. Basically there is no reason to stick to Python 2.x -- just the standard + python is not yet switched on Debian/stable, and so we might miss out on some scripts.] - bash (some test scripts use bash specific extensions) Build Tools ~~~~~~~~~~~ * Git -* SCons *2.0* footnote:[we build with SCons >= 2.0 since a long time. Previously the buildsystem used to work with 1.0 - In addition, we use some SCons plug-ins, which are all shipped in-tree (`admin/scons`)] +* SCons *2.0* footnote:[we build with SCons >= 3.0 since a long time. However, since the times of 2.0, + there are no major breaking improvements we rely on -- so chances are that the Build works fine with + older versions. In addition, we use some SCons plug-ins, which are all shipped in-tree (`admin/scons`)] * pkg-config * Doxygen diff --git a/doc/technical/code/c++11.txt b/doc/technical/code/c++11.txt index 2dd3a70a8..def4bb860 100644 --- a/doc/technical/code/c++11.txt +++ b/doc/technical/code/c++11.txt @@ -12,8 +12,8 @@ language and compiler support wasn't ready for what we consider _state of the cr amended deficiencies by rolling our own helper facilities, with a little help from Boost. Thus there was no urge for us to adopt the new language standard; we could simply wait for the compiler support to mature. In spring 2014, finally, we were able to switch our codebase -to C++11 with minimal effort.footnote:[since 8/2015 -- after the switch to Debian/Jessie -as a »reference platform«, we even compile with `-std=gnu++14`] +to C++11 with minimal effort.footnote:[since 2/2020 -- after the switch to Debian/Buster +as a »reference platform«, we even compile with `-std=gnu++17`] Following this switch, we're now able to reap the benefits of this approach; we may now gradually replace our sometimes clunky helpers and workarounds with the smooth syntax of the ``new language'' -- without being forced to learn or adopt @@ -201,28 +201,11 @@ August 2015:: our »reference system« (platform) is Debian/Jessie from now on. We have switched to **C\+\+14** and use (even require) GCC-4.9 or CLang 3.5 -- we can expect solid support for all C\+\+11 features and most C++14 features. +February 2020:: + our »reference system« (platform) is Debian/Buster from now on. + We have switched to **C\+\+17** and use (even require) GCC-8 or CLang 7 -- we can expect solid support + for all C\+\+17 features. -Perfect forwarding -~~~~~~~~~~~~~~~~~~ -Unfortunately, we ran into nasty problems with both GCC-4.7 and CLang 3.0 here, when chaining several forwarding calls. - -- the new _reference collapsing rules_ seem to be unreliably still. Note that even the standard library uses an - overload to implement `std::forward`, while in theory, a single definition should work for every case. -- in one case, the executable generated by GCC passed a reference to an temporary, where it should have - passed a rvalue reference (i.e. it should have _moved_ the temporary, instead of referring to the - location on stack) -- CLang is unable to pass a plain-flat rvalue through a chain of templated functions with rvalue references. - We get the inspiring error message ``binding of reference to type `std::basic_string` to a value of - type `std::basic_string` drops qualifiers'' - -Thus -- as of 9/2014 -- the _rules of the game_ are as folows - -- it is OK to take arguments by rvalue reference, when the type is explicit -- it is OK to use std::forward _once_ to pass-trough a templated argument -- but the _time is not yet ready_ to get rid of intermediary copies -- we still prefer returning by value (eligible for RVO) and copy-initialisation -- we refrain from switching our metaprogramming code from Loki-Typelists and hand-written specialisations - to variadic templates and `std::tuple` diff --git a/doc/technical/howto/IdeSetup.txt b/doc/technical/howto/IdeSetup.txt index 9d52c4739..901e6e920 100644 --- a/doc/technical/howto/IdeSetup.txt +++ b/doc/technical/howto/IdeSetup.txt @@ -29,7 +29,7 @@ There is nothing really fancy with the configuration, things work as you'd expec actually enabled. This provider is used by the IDE to retrieve definitions from the compiler for syntax checks while you type and for building the search index. Typically, this provider is called ``GCC Builtin Compiler Settings''; please ensure in the global (or the project specific) configuration that the invocation command line includes - the argument `-std=gnu++14` -- otherwise you'll get a lot of red squiggles on the new language features ;-) + the argument `-std=gnu++17` -- otherwise you'll get a lot of red squiggles on the new language features ;-) Indexer troubleshooting ~~~~~~~~~~~~~~~~~~~~~~~ @@ -55,6 +55,20 @@ was able to see the right files with the right locations _manually_ -- more so if they are still accessible on the system. Dont blame the Indexer, which basically has no way to find out he is looking at the obsolete source files... +Sourcecode for relevant external libraries +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Especially when working on the GUI, it can be handy to have some of the most relevant libraries around: +`gdl`, `gdlmm3`, `glib2.0`, `glibmm2.4`, `gtk+3.0`, `gtkmm3.0`. Just extract the source code into a directory +and add it via the ``Makefile Project with Existing Code'' wizard. Of course it helps to some degree if you're +also able to _build_ that code (even partially) from within the IDE, since the indexer is than able to pick up +more cross linking information. However, this is not a strict requirement -- even while `F3` often fails, the +``Open Type'' dialog is able to spot the definition in many cases non the less, and when this fails, you can +still use ``brute-force'' file search. What turns out to be much more an impediment in practice is the fact +that you'll have to jump through that C++ binding layer, and you need to pick up some basic knowledge how +this layer works to wrap the underlying plain-C GTK entities; don't confuse the C++ _wrapper objects_ +with the _gobject_ (a concept from GLib) used by GTK. + + Debugger Breakpoints not working ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This seems to be a FAQ since Eclipse Kepler: If some or all breakpoints just refuse to work and you see diff --git a/doc/user/tutorials/building.txt b/doc/user/tutorials/building.txt index e09f2dcd7..6206894a6 100644 --- a/doc/user/tutorials/building.txt +++ b/doc/user/tutorials/building.txt @@ -1,6 +1,6 @@ Building Lumiera from source ============================ -:Date: 2013 +:Date: 2020 :toc: At the moment you can build Lumiera, start the standard Lumiera GUI and run the @@ -46,7 +46,7 @@ authoritative information about the build dependencies is encoded into the link:{ldoc}/technical/build/SCons.html[build system]. Thus, when the build system aborts, indicating that a never version of some library is required, then usually the build system is right...] -More specifically, you'll need the GNU C/C\++ compiler with C++14 support (Version >= 4.9) +More specifically, you'll need the GNU C/C\++ compiler with C++17 support (Version >= 7) in addition to the following tools and libraries: * link:http://git-scm.com/[Git] (version management system) @@ -63,12 +63,6 @@ The GUI depends on the following: * link:https://wiki.gnome.org/LibRsvg[lib rSVG] * link:https://git.gnome.org/browse/gdl[lib GDL] -CAUTION: there are known problems with *GCC-5.x* as of 11/2015 + - on recent distributions (Ubuntu/wily, Debian/stretch) you might - encounter failing tests.footnote:[these problems aren't really serious; - basically we're sometimes checking mangled class/type names, and seemingly - the mangling behaviour of GCC has changed slightly. We're working on that...] - TIP: Generally speaking, when you want to build software, you'll need the _development_ version of the packages that contain the headers and pre-built libraries to link against. These packages are usually named `-devel` or `-dev`. @@ -81,17 +75,6 @@ libboost-dev libboost-program-options-dev libboost-regex-dev libboost-filesystem libgavl-dev libgtkmm-3.0-dev libgdl-3-dev librsvg2-dev libxv-dev ------------------------------------------------------------------------------------- -Ubuntu note:: - some people reported you need to install the `intltool` package from the standard - Ubuntu repository (for this reason it is included in the above collection) -Mint-17.2 (Rafaela) and Ubuntu 12.LTS:: - we really need the gcc-4.9, so building on these platforms is a bit tricky. See our - link:{ldoc}/technical/howto/backporting.html#_building_on_mint_17_2_rafaela_8201_8212_8201_gcc_and_libstdc_4_9[»Backporting«] - page for detailed info... -GCC-5.0:: - we're aware of some changes in mangled names (or type-IDs), which cause some tests to fail. - Other than that, compilation worked for us. - Build Directory diff --git a/doc/user/tutorials/contributing.txt b/doc/user/tutorials/contributing.txt index 75d7bbb09..d3a5767c8 100644 --- a/doc/user/tutorials/contributing.txt +++ b/doc/user/tutorials/contributing.txt @@ -268,7 +268,6 @@ Steam Layer:: * implement a command dispatcher to allow blocking and queuing of commands * develop a scheme how to code the GUI commands in practice -- implement a symbol table for the `lib::Symbol` datatype - provide the foundation for symbolic rules and script bindings * expand on the work done for symbolic and hash references diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 03d827485..fd5aa9024 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -44515,8 +44515,8 @@ - - + + @@ -44933,12 +44933,13 @@ - + - + - + + @@ -44973,6 +44974,9 @@ + + + @@ -45237,8 +45241,8 @@ - - + + @@ -45335,8 +45339,8 @@ - - + + @@ -45501,14 +45505,14 @@ - + - - + + - - + + @@ -45594,9 +45598,9 @@ - + - + @@ -45643,7 +45647,7 @@ - + @@ -45654,15 +45658,16 @@ - + - - + + + - + @@ -45675,24 +45680,24 @@ - + - - - - - + + + + + - + - - - + + + @@ -45715,8 +45720,8 @@ - - + + @@ -45739,15 +45744,15 @@ - + - - - + + + - - - + + + @@ -45765,14 +45770,14 @@ - + - + - - + + @@ -45785,31 +45790,31 @@ - + - - + + - + - - + + - + - + - + - + @@ -45828,8 +45833,11 @@ - - + + + + +