This is a bit of a detour, since it's not about autoconf, but a different and I
think better solution to the same problem.
To start, I'd like to make my bias clear and upfront:
I'm a developer for Rogue Wave Software (www.roguewave.com), where we sell
cross platform C++ libraries. I _have_ gone ahead and talked to some of the
higher ups to make sure I don't piss anyone off, but I'm speaking for myself --
largely because I think the project I work on is fairly cool!
Over the past 10 years we've tried several solutions to deal with the
maintenance costs associated with cross platform building, including trying to
support an unwieldly makefile system like the original poster describes.
After determining that such things as autoconf didn't meet our needs, we've end
up creating our own system, called RCB.
RCB uses a java engine that generates makefiles, which it then uses to build
our libraries as well as their examples and tests. This is hooked into our
build and test manager (Batman!), allowing us to continously test various build
configurations on all of the platforms we support.
We use XML to specify how the makefiles should be built, describing both the
parts that are common, and the things that differ, such as compiler flags, etc.
RCB also uses XML to describe the "products" to be built, and which build
variations (static or dynamic linking, threading library, compiler/os, etc.)
they support.
A Java gui is used to create a reusable text file that defines what is going to
be built, and how it will be built (e.g. debug, or release?). The gui also
makes sure that only valid combinations are selected, and that the proper
required libraries are defined.
Adding new products and giving them cross-platform support and _testing_ is a
matter of creating xml that lists the source files, etc. that are a part of the
library, what other libraries it requires, and perhaps some custom flags, or
constraints on which platforms and buildtypes are supported.
I really think this is the way to go, as it has cut our maintence costs,
improved our testing, and allows more flexibility than our previous systems.
Our customers seem to generally think it's an easier system to use as well.
I couldn't imagine moving to autoconf, or going back to supporting a bunch
of platform specific makefiles
Personally, I think it would be cool if others were to use the system I've
put so much time into, although I can understand the attraction of using
more commonly available (and free!) tools. Still, I think RCB has a lot
to offer.
We've tossed around the idea of selling the system to others who face similar
problems, or perhaps even open sourcing it, but it's only just now starting to
become robust enough that this is feasible.
Feel free to send me email if you're curious about any of this.
Coke is nothing like a RPG. I don't know anyone who makes soda anymore, but _every_ gamemaster I know modifies the rules of the game they're running at least a little -- more jaded gamers often aren't satisfied otherwise. Sometimes these systems are good (especially compared to D&D), and if you put a lot of work into it, why not try to sell what you have? It'd be easier than writing a new game, games often evolve this way, and people are more likely to pick up a presumably cheaper flavor of a system they're familiar with than something entirely new. If parts of the d20 system were modular, D&D might even begin to have some appeal again. Of course, is this really different than what GURPS has done for more than 10 years? The 3d6 system...
Slashdot Mirror
No, it would make message sent in such a manner uncrackable.
Sure, a single _bit_ could be intercepted, but as soon as that is done, the sender can simply stop transmitting.
The end result leaves the interceptor with nearly zero information. Not very usefull.
This is a bit of a detour, since it's not about autoconf, but a different and I
think better solution to the same problem.
To start, I'd like to make my bias clear and upfront:
I'm a developer for Rogue Wave Software (www.roguewave.com), where we sell
cross platform C++ libraries. I _have_ gone ahead and talked to some of the
higher ups to make sure I don't piss anyone off, but I'm speaking for myself --
largely because I think the project I work on is fairly cool!
Over the past 10 years we've tried several solutions to deal with the
maintenance costs associated with cross platform building, including trying to
support an unwieldly makefile system like the original poster describes.
After determining that such things as autoconf didn't meet our needs, we've end
up creating our own system, called RCB.
RCB uses a java engine that generates makefiles, which it then uses to build
our libraries as well as their examples and tests. This is hooked into our
build and test manager (Batman!), allowing us to continously test various build
configurations on all of the platforms we support.
We use XML to specify how the makefiles should be built, describing both the
parts that are common, and the things that differ, such as compiler flags, etc.
RCB also uses XML to describe the "products" to be built, and which build
variations (static or dynamic linking, threading library, compiler/os, etc.)
they support.
A Java gui is used to create a reusable text file that defines what is going to
be built, and how it will be built (e.g. debug, or release?). The gui also
makes sure that only valid combinations are selected, and that the proper
required libraries are defined.
Adding new products and giving them cross-platform support and _testing_ is a
matter of creating xml that lists the source files, etc. that are a part of the
library, what other libraries it requires, and perhaps some custom flags, or
constraints on which platforms and buildtypes are supported.
I really think this is the way to go, as it has cut our maintence costs,
improved our testing, and allows more flexibility than our previous systems.
Our customers seem to generally think it's an easier system to use as well.
I couldn't imagine moving to autoconf, or going back to supporting a bunch
of platform specific makefiles
Personally, I think it would be cool if others were to use the system I've
put so much time into, although I can understand the attraction of using
more commonly available (and free!) tools. Still, I think RCB has a lot
to offer.
We've tossed around the idea of selling the system to others who face similar
problems, or perhaps even open sourcing it, but it's only just now starting to
become robust enough that this is feasible.
Feel free to send me email if you're curious about any of this.
-Jasper
phillips@roguewave.com
jasper@peak.org
Coke is nothing like a RPG. I don't know anyone who makes soda anymore, but _every_ gamemaster I know modifies the rules of the game they're running at least a little -- more jaded gamers often aren't satisfied otherwise. Sometimes these systems are good (especially compared to D&D), and if you put a lot of work into it, why not try to sell what you have? It'd be easier than writing a new game, games often evolve this way, and people are more likely to pick up a presumably cheaper flavor of a system they're familiar with than something entirely new. If parts of the d20 system were modular, D&D might even begin to have some appeal again. Of course, is this really different than what GURPS has done for more than 10 years? The 3d6 system...