[Coin-symphony] now my code is being called, but

[Michael Hennebry]

On Thu, 24 Feb 2005, Ted Ralphs wrote:

> I guess there wasn't really a question in your last post, but you've got
> me thoroughly mystified, so let me ask a few questions.
>
> First, why is it that you need to use your own makefile? Do you just

Probably I don't, but when compiling my code,
I prefer a make file that I can read.
Black magic is for other people's stuff.

Also, this way I can specify the compiler flags that I want.
Possibly it can also be done with Symphony's build system,
but I can't tell.

> want to have control and don't want to compile your code using a black
> box? I can't see anything you're doing that wouldn't be easy accomplish
> using SYMPHONY's build system, where all the compiler defines are set
> automatically for you. You should have no problems at all if you just
> copy the makefile in the USER directory and customize it. ...

That is what I started with.  It worked.
A colleague was having trouble with segmentation faults,
so, earlier than I otherwise would have, I copied my stuff
from inside the Symphony tree and tried to use a standalone
make file.  It didn't work.
Some of my callbacks weren't being called.  I don't remember why.
It might have been the wrong library.
My next effort core dumped.
Adding the correct -D flags did the trick.

> ...                                                       We are
> actually in the midst of revamping SYMPHONY's build system to make it
> easier to work with. If you get the latest version from CVS, the
> makefiles have some added flexibility. In particular, you can specify a
> build directory outside the source tree.

I've got the latest.
As you implied earlier,
rearranging directories under CVS is interesting.
Good work.

> Second, I'm not sure why you need all those compiler defines in the
> first place. None of them are required for the user callback functions.
> If you grep on "ifdef" in SYMPHONY/Applications/USER/src/*/*.c, you will
> find that there are actually no compiler directives that have any
> effect. Compiling your code and linking it with no compiler defines
> should work unless you are trying to build parts of SYMPHONY itself.
> What am I missing?

The header files.
The libraries and the user code have to agree on the data structures.
There are ifdef's in header files that affect the numbers of items
in structures.

> As for documentation, maintaining SYMPHONY and all its documentation at
> the level it's at is a huge amount of work. I simply don't have the
> funding or manpower to do more, especially to document the interior
> parts of the library and build system. If you would just stop trying to
> do things you're not supposed to do, you wouldn't be having these
> problems :). ...

"Stay out of those places."

> ...          At any rate, documentation is always an issue. I'd be happy
> to have help if you want to contribute some of your recent insights in
> the form of additional or updates to the current documentation. Thanks
> for your feedback. Let me know if you have any more questions or problems.

That is why I didn't grouse about what you ought to be doing.
Symphony is a pretty good `buy' as-is.

Here is an entry to file under makefiles/user/independent:
Some ifdefs affect the definitions of data structures.
For correct operation, it is essential that user code use
the same definitions as the library.  To this end,
COMPILE_IN_CG, COMPILE_IN_LP, and COMPILE_IN_TM must each
be defined or not to match the compilation of the library.
__OSI_CLP__ or one of its siblings must be defined.
It is also a good idea to define HAS_RANDOM or not,
depending on whether your system has the function random.

I had been going to suggest that you not use ifdef's around
elements of structure, just let some elements go unused if
they are not needed.
Since some of the ifdef'ed sections are major fractions of
their entire structures, doing so might be too much of a waste
of memory.

--
Mike   hennebry at web.cs.ndsu.NoDak.edu
"Our gods are dead.  Ancient Klingon warriors slew them
... they were more trouble than they were worth."          --  Worf