RFS: EngLab

[Bernhard R. Link]

* Harry Serenis <chserenis at ee.auth.gr> [081004 00:37]:
> I am a developer of a fairly new project called EngLab. It is intended
> to be a mathematical platform / programming language such as Matlab
> and Octave but *not* a Matlab clone. It has a C like syntax, native
> support for many data types, allows variable declarations and has a
> interface for external functions written in C++. (If you would like
> more info please visit our site at http://englab.org.)

Package related:

Your building is quite strange. You do not build anything in build but
build the software in binary, doing both building and installing in a
target s called build-*. (I understand you do this to get the different
versions with different options, but you should at least change the name
of the build-so and build-a rules to reflect them not only building or
(much better) make your build system support out-of-tree builds so you
can build both versions at the same time).

The differentiation of compile flags you use is also quote non-standard:
you use the optimized flags for the shared library, but no optimisation
for the static library. (When you want versions to debug, the normal way
is either letting users build their own version with noopt/nostrip or
to have an -dbg package with easier to debug packages, having this
mixture is at least strange).

Why does binary-indep depend on build-so?

You do compile without any warnings at all. Please add at least -Wall
to CXXFLAGS. That usually makes lives for porters (and yourself) much
easier.

Upstream issues:

Having a non-standard build system makes it quite hard to understand.

1)
There seems to be some strange way for out-of-tree builds (via ${OUT}),
but only for objects while the current build config and Makefiles are
stored to the source directory.
(Not a fatal problem, but many people like a working out-of-tree build
mechanism and it is sometimes quite handy).

2)
Having a soname with two numbers is unusual, calling the numbers making
up the library major and minor might leed to confusion.

Just to make sure what this scheme means for your development:

There is no real difference between VER_MAJOR and VER_MINOR.
Neigther should change unless you remove functionality. (as they give the
soname and every program has to be recompiled when this changes).

If you only add functionality, you should only increase VER_REVISION,
but not VER_MINOR. (as the later is part of SONAME).

I think that this can become very confusing and you might want to
reconsider that.

It might make future changes generally a bit easier, if you add version
symboling (needs some version script to be given to the linker to tell
which symbol is which version). (But note that if that works properly,
then neither VER_MAJOR nor VER_MINOR should change at all in the
future).

3) Compiling your source with warnings enabled (even when only -Wall)
gives a large amount of warnings, please try to reduce those (at least
unused variables, returning non-void functions without return, comments
inside command and things like that are really easy to fix...).

There might be more issues, but I run out of time...

Hochachtungsvoll,
	Bernhard R. Link