Project

General

Profile

News

irccd: Absolute paths forbidden in some CMake options

Added by David Demelier about 3 years ago

Starting with revision r101 (and future 2.1 version), irccd now completely disallow absolute paths for the following options:

  • WITH_BINDIR,
  • WITH_CACHEDIR,
  • WITH_CONFDIR,
  • WITH_DATADIR,
  • WITH_PLUGINDIR.

Background

It is highly recommended to make relocatable software. But what does that mean really? It means that wherever the application is installed, you can safely move it to an another location without recompiling it and the application can still run. The only requirement is to keep the same hierarchy.

In the case of irccd, it uses the following defaults on Unix:

  • WITH_BINDIR: bin/
  • WITH_CACHEDIR: var/irccd/
  • WITH_CONFDIR: etc/
  • WITH_DATADIR: share/irccd/
  • WITH_PLUGINDIR: share/irccd/plugins/

Thus, when irccd is installed in bin/ directory, it knows how to go to the configuration directory by going upward a directory and then in etc/ directory. This is done by retrieving the executable path. This means you can safely install irccd into any directory and then move it somewhere else.

Example:

cmake . -DCMAKE_INSTALL_PREFIX=/tmp/irccd-test
make install

Now, /tmp/irccd-test/ is filled with bin/, etc/ and such. I can safely move /tmp/irccd-test/ somewhere else, irccd will still knows where to locate its directories.

Why disallowing absolute paths

Irccd's CMake process builds the project into a fake root directory, in ${CMAKE_BINARY_DIR}/fakeroot. This makes easier to test irccd without installing it as the fake root directory already simulates the installed project. It makes also much easier for packagers to determine the installed files as they are exactly the same upon installed.

But to use this fakeroot directory, users must not use absolute paths as CMake options are appended to it, thus, setting WITH_BINDIR to C:/Irccd/bin will define the path to ${CMAKE_BINARY_DIR}/fakeroot/C:/Irccd/bin which is indeed invalid.

To fix this, a warning was shown telling that absolute paths are not recommended and fakeroot was disabled in this case, ending with a lot of conditionals in CMake, polluting the readability.

As it's not usually needed to change these directories and to facilitate irccd's development, it's not possible to make them absolute anymore.

But I want to mix / and /usr/local!

While I think you should keep everything belong to the CMAKE_INSTALL_PREFIX variable, it's still possible to tweak the installation to use different parent directories.

cmake . -DCMAKE_INSTALL_PREFIX=/ -DWITH_BINDIR=usr/local/bin -DWITH_CONFDIR=etc -DWITH_DATADIR=usr/local/share -DWITH_CACHEDIR=var/irccd -DWITH_PLUGINDIR=usr/local/share/irccd/plugins

With that invocation, you'll get irccd installed like this:

  • WITH_BINDIR: /usr/local/bin/irccd(ctl)
  • WITH_DATADIR: /usr/local/share/irccd
  • WITH_CONFDIR: /etc/irccd(ctl).conf
  • WITH_CACHEDIR: /var/irccd
  • WITH_PLUGINDIR: /usr/local/share/irccd/plugins

Incoming improvements

Anyway, these CMake options only alter defaults and a new feature to include more paths in the configuration file will be added soon, see #470.

irccd: Irccd 3.0 will be written in Java (2 comments)

Added by David Demelier about 3 years ago

Background

It's been a long time I was thinking about leaving C++. The problem with C++ is that it's a language from the past. It's important nowadays to move towards new technologies such as Node.js, Java 8, Rust and such.

All these new technologies facilitate deployment, collaboration and evolving features.

There are much more people who know these languages than C++. I've written C++ for several years and now I think I should just jump on something else to improve my skills.

Why Java?

I know Java very well as it was one of my preferred language at school and in my internships.

Java is performant, easy, convenient and portable. With Java, no problems: write once, run everywhere.

I already checked the IRC library and there is a good one called PircBot which is also opensource.

When?

I think irccd 3.0 will not be released after at least seven years. Probably in 2023. Irccd consists of somewhat 18000 lines of code at this time. However as Java require less code, the port won't be so difficult.

irccd: Deleting 1.x documentation

Added by David Demelier about 3 years ago

The old 1.x documentation hosted on the Wiki will be deleted the 2016-03-13. Users are encouraged to switch to irccd 2.0.0 as irccd 1.1.5 is not maintained anymore.

irccd: 2.0.0

Added by David Demelier about 3 years ago

I'm glad to announce the availability of irccd 2.0.0 after more than two years of development.

This new version has lots of amazing new features.

Switch to JavaScript

This major version brings a new JavaScript API instead of Lua for developing plugins.

Lua was dropped for JavaScript after many disappointments about Lua's development model, features, design choices.

JavaScript was chosen because it is light, easy to sandbox and easy to learn.

The current implementation inside irccd uses duktape 1.4.0.

Transports

New transports (formerly listeners) have joined irccd.

Transports replaces listeners and are now completely two-ways.

This means that you can connect to an irccd instance and wait forever for new messages. Irccd will broadcast new messages for each IRC event, this lets you create innovative plugins even without JavaScript.

See the irccdctl watch command which uses transports.

Rules

A brand new feature similar to firewalls can now let you enable or disable events on specific criterias.

It is now possible to disable some IRC events for a specific plugin!

This lets you keep some channels where you don't want some kind of gaming plugins.

Example, this rule disables the plugin hangman on #mychannel@myserver.

[rule]
servers = "myserver" 
channels = "#mychannel" 
plugins = "hangman" 
action = drop

Logs

The logging mechanism in irccd has now its dedicated logs section.

It can now save logs to files.

Example:

[logs]
type = file
path-logs = "/var/log/irccd/log" 
path-errors = "/var/log/irccd/errors" 

More unixish options

Good daemons must have good features, the following options were added in general section:

  • uid, to change the daemon uid,
  • gid, to change the daemon gid,
  • pidfile, where to save the pid file.

Plugins

The following new plugins were added:

The following plugins where removed:

  • antiflood, currently suspended, will come back later,
  • badwords, no plans to replace it,
  • date, no plans to replace it.

New doc, new website

The documentation is now completely built within the irccd repository, making easier to show, update before a new release.

The documentation is completely built with pandoc.

As you can see, the website has completely changed with a brand new design based on bootstrap.

Improved parser

The parser can now understand multiple options on the same line (not recommended though):

[section]
option1 = value1 option2 = value2

It also understands a new include keyword, this allows splitting the configuration into multiple different files.

Note: the instruction must be at the beginning of the file.

# Comments are allowed though
@include "foo.conf" 
@include "baz.conf" 

[section]
option = value

The parser can also use lists in some options using parentheses.

[section]
option = ( "value1", "value2" )

New common patterns

The common pattern syntax has evolved in various way, they now require braces, environment variables are supported, colors and attributes are also supported.

The default keywords have been renamed to:

  • #c -> #{channel},
  • #m -> #{message},
  • #s -> #{server},
  • #t -> #{topic},
  • #T -> #{target},
  • #u -> #{origin},
  • #U -> #{nickname}.

The following keywords have been added:

  • #{command}, the full command invocation (e.g. !ask),
  • #{plugin}, the plugin name.

See the documentation for more examples about new syntax.

Monothread architecture

The irccd 1.x architecture was highly threaded and terribly complex. The new irccd 2.0.0 architecture has 0 threads except when adding new timers from the JavaScript API.

New installer

The Windows installer is now based on QtIFW and lets you selecting which components to install.

nsnake: 2.0.0

Added by David Demelier about 3 years ago

I'm glad to announce the availability of nsnake 2.0.0.

Available for Windows

Thanks to pdcurses, nsnake is now fully compatible with Windows using MinGW or Visual Studio. The library is bundled with nsnake so the user has nothing to install before.

Switch to CMake

To port nsnake easily, I have switched to CMake. The build system is now able to:

  • Check if the user/group games are available on the system (unix only),
  • Create the score directory with the appropriate permissions for sharing scores,
  • Check functions, headers and such.

Clean up

The source code has been cleaned up a lot.

(11-20/31)

Also available in: Atom