shared_lib

[daniel.santos]

Is there a good reason why we have separate directories for includes & sources in the shared lib?

[silnarm]

Because it's inconsistent and inconvenient, and that's the GAE way ?

[hailstone]

When you distribute a library you usually have a .lib/a file instead of the implementation files. Having them separate makes it easier to remove the implementation files. Since shared_lib is not likely to be distributed without sources I think it was done by convention just in case rather than practicality.

[daniel.santos]

ahh, thanks hailstone!

Well, if we decide to have the library really be a shared library, we can have an install that just installs the headers.   So what do you guys say we just move everything from sources/shared_lib/{include,sources} to sources/shared_lib?

[silnarm]

I say, 'good idea'. 

[hailstone]

I haven't merged the trunk with any of my branches for a while so they are going to be 'really' out of sync if this happens. I think we should stick it on a TODO for after v0.3.

[daniel.santos]

OK, that sounds fair enough.  I admit that I'm not a big fan of merging and I've learned a few lessons on it.  I did it all manually (i.e., not depending upon "svn merge") with kdiff3, but any descent 3 diff program should work.  Also, I merged the "glest_game" with "game" and glest_map_editor" with "map_editor" separately, and then did the rest of the tree.

[daniel.santos]

hailstone,
I really want to get the major project changes all out of the way and I think this is the last one.  So I would rather do it sooner than later.  Maybe I can help with your merge?

[hailstone]

Perhaps tag the trunk first then the next version can be dedicated to project changes. I'm not likely to make any changes until next week since I have exams soon.