Merging GRFCodec & NFORenum sources

[Rubidium]

The GRFCodec and NFORenum sources are sharing some data; actually they have a file in common for some action 2, 7 and D escapes (e.g. \7!) which should be synced between GRFCodec and NFORenum. To ease this we intend to merge the source packages. For build requirements it doesn't matter anything as both GRFCodec and NFORenum need BOOST.

As a result of this the GRFCodec and NFORenum packages (releases and nightlies) will be merged as well which should not be a problem. Yes you might download a package that's slightly bigger but you'll have both GRFCodec and NFORenum updated.

The "problem" we have is the naming of the new package. We're not sure what way to go; keep the GRFCodec name for the whole package, even when it includes NFORenum, or use another slightly more descriptive name such as grfdevtools? However grfdevtools might imply that it includes other grf development tools such as grf2html and grfmaker as well. Does anyone have an opinion about which name to use name or maybe a better name?

[WWTBAM]

I would keep GRFCodec.

[Lord Aro]

I would keep GRFCodec.

+1
oh, and a poll might be useful as well (stops people like me making mostly useless posts )

[michael blunck]

The GRFCodec and NFORenum sources are sharing some data; actually they have a file in common for some action 2, 7 and D escapes (e.g. \7!) which should be synced between GRFCodec and NFORenum. To ease this we intend to merge the source packages. [...]

As I understand it, this could be "only" a problem with the source which has to be released due to both programs being GPLed. Except from this, I don´t understand why "syncing" two programs but distributing them individually should be a problem at all.

Anyway, in case this should happen, I´d say stay with grfcodec, simply because this is the main tool, nforenum being "only" an auxiliary tool, i.e. not mandatory.

regards
Michael

[FooBar]

GRFTools

[wallyweb]

GRFCodec++

[planetmaker]

grfcodec

[Rubidium]

poll might be useful as well

Actually, then anyone (even those that don't use it at all) votes anonymously and I still don't have a clue what the actual users/people with interest in it think.

GRFTools

This has the same problems as grfdevtools (maybe even slightly more).

I don´t understand why "syncing" two programs but distributing them individually should be a problem at all.

It's not a problem, it's more a hassle; the effort for a release is essentially doubled at all places in the chain. Checking changelogs, readmes and such in two repositories, writing two release notes, people having to download two packages, downstreams (distros) having to update two packages.
It would be perfectly possible to create two binary packages though, but in my opinion the drawbacks of that outweigh the benefits. Downstreams are still able to keep two different packages if they like to.

GRFCodec++

That's not significantly better/more descriptive than GRFCodec, though the best alternative to GRFCodec I've seen so far. In any case I was intending to bump the version significantly if we'd stay with GRFCodec; something 5.x.y, so it's bigger than NFORenum's and GRFCodec's version.

[WWTBAM]

GRFCodec++

I like that as well if not more than GRFCodec.

[frosch]

How about dropping the "grf" part?

There are various ways to create grfs, with nml or with grfmaker.
Otoh nforenum does not deal with grfs at all.

So I would rather go for "nfotools", "nfokit", ...

[Froix]

I kinda like the GRF part myself. Am I right in assuming Codec stands for compiler and decompiler?

GRFCode, GRFCode+ - I like shorter names.
GRFCom - GRF Compiler
GRFCom+ - GRF Compiler and more
GRFPro - GRF Processor or GRF Professional

[michael blunck]

It's not a problem, it's more a hassle [...]

Well, if it´s only about the name of the package, anything could work, given that both programs retain their original name. BTW, "grfcodec" is an already well-known term in the Unix/Linux world, have a look at google.

regards
Michael

[Alberth]

I would consider the merge as grfcodec getting extended functionality, namely annotated nfo output. You should probably add flags to allow the user to specify what he wants.

To ease the mind of people wanting to keep both tools, you could check argv[0] to decide on the default flag option settings, a trick often employed to deploy several closely related programs:

Code: Select all

$ ls -li /bin/ed /bin/red
87585 -rwxr-xr-x. 2 root root 53352 Jul 25  2009 /bin/ed
87585 -rwxr-xr-x. 2 root root 53352 Jul 25  2009 /bin/red

For people less familiar with the -i option of ls, the first number in both lines is the inode number, the unique ID number of a file at a file system. Since it is the same, both programs are really the same file, it just has two names. Depending on which name you use to start the program, it does something different.

[planetmaker]

In the light that these tools basically deal with the nfo language (and considering that most tools tell what they take as input, e.g. asm (assember files) ,gcc, msvc (c files), photoshop (photos), ... and not their output (binary, exe, graphics), frosch's proposal to call it like 'nfotools', 'nfokit' or maybe 'nfoc' might seem the more logical choice.

Alberth's proposal might seem a good idea, too; though I'm not sure how far that can be realized on windows systems.

[Rubidium]

I'm not talking about merging the GRFCodec and NFORenum binaries, just their source packages. There will still be a grfcodec and nforenum (and grfmerge/grfdiff) binaries after the merger.

NFOTools might be an alternative name, although it doesn't quite cover grfmerge and grfdiff. I'd still favour GRFCodec.

[andythenorth]

GRFCodec +1

[Yexo]

GRFCodec +1

[wallyweb]

I'm not talking about merging the GRFCodec and NFORenum binaries, just their source packages. There will still be a grfcodec and nforenum (and grfmerge/grfdiff) binaries after the merger.

Sorry for the jocularity, but I simply can't resist this ... How about "That Thingamajig Used To Check NFO Code AND Spit Out A GRF" ?
The point here is that we would be looking at a package that performs two or more functions. The output of this tool is a grf file, and failing that, a suitably commented nfo file that points out the error(s) of our ways, as well as being a tool that can decode a grf file. Consequently, something in keeping with GRFCodec would seem most appropriate. "GRFWizard" has already been claimed.