forum.alglib.net

That will kill 2 birds with one stone, so to say: (1) an example of use, and (2) a ready-made regression tester.

Hi!

Such testing is already done, without make, using console scripts (Unix and Windows-specific). Given ALGLIB monolithic design, Bash turned out to be more than enough. We ran our tests regularly.

Yes, this is true, but for those who are new to ALGLIB, a makefile will serve both the purpose of demonstrating how to include it in their program and to provide something for performing tests on the code; particularly if they make changes or additions to it.

It also helps keep better track of the dependencies and to perform updates in a more intelligent manner; and the dependencies help one to determine which modules are required for a project.

Independent of the issue of whether a reference makefile is included or not, the following information should prove helpful for ALGLIB users.

These are a list of all of the direct dependencies.
Optimization -> Solvers -> LinAlg -> AlgLibMisc -> AlgLibInternal -> Ap -> (for MSVC) StdAfx
Integration, Statistics -> LinAlg, SpecialFunctions
Interpolation -> Integration, Optimization
DataAnalysis -> Statistics, Optimization
DiffEquations, FastTransforms, SpecialFunctions -> AlgLibInternal
Test_C, Test_I, Test_X -> DataAnalysis, DiffEquations, FastTransforms, Interpolation

In my local version, I've eliminated #includes except those for direct dependencies and made other changes (many).

The "using namespace std;" and MSVC #pragma statements need only be listed in Ap.h, not in the *.cpp files, as long as the #include statements are listed first.

A *.cpp file only needs to include its companion *.h file and each *.h file only needs to include the *.h files for the modules that its own module directly depends on.

In a Makefile for my copy of the library, I only include dependencies for
*.cpp: *.o
*.o: *.h
A.h: B.h, for each direct dependency A -> B.
A.o: B.o, for each direct dependency A -> B.
Note: not all submodules of a given module have the given direct dependency, but will usually have indirect dependencies once or more removed, such as can be derived from this list. The simplest way to test this is either with a profiling tool or to try to compile the submodule with the dependency or dependencies removed.

Hi!

1. Frankly speaking, I have mixed feelings on this question (direct vs indirect deps) :) It is beautiful in some way... but someone may decide that he wants to have all dependencies (direct or indirect) listed in one place. Because some users prefer to compile only those packages which are required.

2. On using namespace and pragma's: took your point, agree. I will study it in more details in the next few days, maybe these changes will be included in the upcoming release.

I see the issue now, with your latest revisions: you really want dependencies for the subpackages, rather than the packages. This creates a strong push to go back to the pre-version-3 file layout; with it looking more like LAPACK or GMP in terms of its layout.

It's still possible to have it both ways by putting lines in a Makefile that concatenate a package file from its subpackage files. I'm going to experiment with this and other compromise solutions.