Thread: [DM-dev] New Release
Brought to you by:
acdalton,
henningsen
Menu
▾
▴
dungeonmaker-develop
|
From: Aaron D. <aa...@da...> - 2005-12-07 05:39:01
|
Version 2.04 has been released. This release contains no functional changes but now uses the GNU build system. This release can now be built as a shared library using the standard ./configure system. To install now: $ ./configure $ make # make install This is personally my first time using autoconf, automake, and libtool. Any suggestions or input others with more experience might have would be warmly received. -- Aaron Dalton | Super Duper Games aa...@da... | http://superdupergames.org |
|
From: stephan b. <st...@s1...> - 2005-12-07 19:14:16
|
On Wednesday 07 December 2005 06:39, Aaron Dalton wrote: > $ ./configure > $ make > # make install > > This is personally my first time using autoconf, automake, and > libtool. Any suggestions or input others with more experience might > have would be warmly received. Hi, Aaron! i'm personally a huge hater of Autotools, but i also firmly believe that=20 whoever is actually maintaining the tree should be the one to decide=20 what tools to use. i personally use "toc" (the other configure):=20 http://toc.sourceforge.net (Disclaimer: i wrote it! ;) In short, toc is "a GNU build system targeting only GNU platforms." It's=20 intended to be a replacement for projects which only target (at least=20 at the *build* level) GNU systems. It's MUCH easier to maintain and has=20 many maintenance benefits (IMO) over autotools. However, it won't build=20 anything on, e.g., a 1990's SCO box. It needs GNU versions of the=20 common Unix tools. :) =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Aaron D. <aa...@fr...> - 2005-12-08 06:22:59
|
stephan beal wrote: > Hi, Aaron! > > i'm personally a huge hater of Autotools, but i also firmly believe that > whoever is actually maintaining the tree should be the one to decide > what tools to use. i personally use "toc" (the other configure): > http://toc.sourceforge.net > There is no reason we cannot support multiple systems. As the author of TOC, if you would be willing to put together a distribution, I would be happy to release a separate package. I would also be happy to learn how to keep it maintained myself as I upgrade the software so you don't have to redo it every release. Cheers! -- Aaron Dalton aa...@Fr... FreeBSD Ports Committer |
|
From: stephan b. <st...@s1...> - 2005-12-08 21:57:19
|
On Thursday 08 December 2005 07:24, Aaron Dalton wrote: > There is no reason we cannot support multiple systems. As the author > of TOC, if you would be willing to put together a distribution, I > would be happy to release a separate package. I would also be happy > to learn how to keep it maintained myself as I upgrade the software > so you don't have to redo it every release. Excellent. We did that for the pclasses.com source tree. The only tiny=20 caveat was that in CVS we had the toc 'configure' script and Makefiles=20 and Autotoolers had to delete those and generate their own. Autotools=20 and toc have been proven to coexist sanely in the same project tree.=20 i've got a few days off week after next and i will definitely whip you=20 up a tree. To state the main caveats up front: =2D GNU systems only. Any variant of Linux. Has been known to run on=20 Solaris and BSD systems, provided they host GNU variants of the most=20 common Unix tools (sed, find, make, tar, etc). Cygwin might or might=20 not work. i don't think i ever got linking shared libs working on=20 Cygwin, and don't have a Windows box anymore to try it on. =2D The variety of built-in configure checks isn't nearly as broad (but=20 it's easy to extend). That said, since the build tools target only GNU=20 systems, there aren't nearly as many compatibility checks needed. There are numerous advantages, but i'll shut up now. :) TTYS, =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Aaron D. <aa...@fr...> - 2005-12-08 23:17:48
|
stephan beal wrote: > On Thursday 08 December 2005 07:24, Aaron Dalton wrote: > >>There is no reason we cannot support multiple systems. As the author >>of TOC, if you would be willing to put together a distribution, I >>would be happy to release a separate package. I would also be happy >>to learn how to keep it maintained myself as I upgrade the software >>so you don't have to redo it every release. > > > Excellent. We did that for the pclasses.com source tree. The only tiny > caveat was that in CVS we had the toc 'configure' script and Makefiles > and Autotoolers had to delete those and generate their own. Autotools > and toc have been proven to coexist sanely in the same project tree. > i've got a few days off week after next and i will definitely whip you > up a tree. > > To state the main caveats up front: > > - GNU systems only. Any variant of Linux. Has been known to run on > Solaris and BSD systems, provided they host GNU variants of the most > common Unix tools (sed, find, make, tar, etc). Cygwin might or might > not work. i don't think i ever got linking shared libs working on > Cygwin, and don't have a Windows box anymore to try it on. > > - The variety of built-in configure checks isn't nearly as broad (but > it's easy to extend). That said, since the build tools target only GNU > systems, there aren't nearly as many compatibility checks needed. > > There are numerous advantages, but i'll shut up now. :) > > TTYS, > Yeah, I'm not sure how I'll organize CVS, but we'll work it out =) Thanks! -- Aaron Dalton aa...@Fr... FreeBSD Ports Committer |
|
From: stephan b. <st...@s1...> - 2005-12-09 16:37:35
|
On Friday 09 December 2005 00:17, Aaron Dalton wrote: > Yeah, I'm not sure how I'll organize CVS, but we'll work it out =3D)=20 If i may say so, i've got a lot of experience structuring C++ source=20 trees, and a &h!t load of opinions on the topic ;). The current tree is really flat, i'd like to see it separated like so: src/ src/dm =3D core lib code. name needn't be 'dm' src/ui or src/dm/ui =3D UI-centric lib code. src/client =3D client app(s) go here. e.g. src/client/console src/client/sdl src/client/example include/sf.net/dm2 The includes can live under src/dm, but should be copied/symlinked under=20 include/... during the build process. Another alternative is to move=20 the headers under include/... The sources should only reference the=20 headers using <sf.net/dm2/foo.hpp>, rather than "foo.hpp", IMO. This general structure has shown to be very extendable as a project=20 grows. The headers conventions also enforce non-circular dependencies=20 in the various subcomponents. If the copy/symlink approach is used,=20 cyclic deps become impossible because they'll break the first time the=20 tree is built (before all headers are installed under include/...). i've got lots more to say on build trees, but i'll shut up :). =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X