+1 to rename daffodil-codegen-c.
My one concern about dropping the "daffodil-" prefix in general is that
it becomes hard to differentiate between directories containing code and
those containing infrastructure stuff (e.g. containers, scripts, sbt
dirs). This is especially the case if we renamed daffodil-lib to just
"lib/" and "lib_managed/" (sbt jar storage) stayed the same.
Maybe we do something like add a new root dir that all the subprojects
go in (eg. src/codegen-c, src/lib, src/cli). I would prefer something
like this over shortening the prefix to "daf-", feels like it organizes
things a bit better.
Though, whatever the change, and I don't think we need have to figure it
now, I suggest we hold of and do all projects at the same time. So for
now just rename to daffodil-codegen-c, keeping the daffodil- prefix.
Note that we also can change the names of the directories and add
subdirectories without changing the jar names. The jar names probably do
always want to have the daffodil- prefix. For example, a jar named just
"lib-XYZ.jar" instead of "daffodil-lib-XYZ.jar" could cause a lot of
confusion otherwise.
On 2023-02-03 08:11 PM, Interrante, John A (GE Research, US) wrote:
We only discussed shortening the daffodil- prefix to daf-, not eliminating it. We wrote up that
discussion in https://issues.apache.org/jira/browse/DAFFODIL-2406. We put off changing any
daffodil- module names until Daffodil's 4.0.0 release, however, because changing the module names
would be quite disruptive. All schemas' and users' build.sbt that pull in daffodil for testing
would need to change not only version numbers, but also jar names. Arguably, longer names that say
"daffodil" is good for the jars since we can see a list of jar files in a directory and
know which jars come from Apache Daffodil modules and which jars come from external libraries. The
"daffodil" in names is only clumsy for developers who have to type those names fairly
often.
We also have a wishlist for a sbt plugin to simplify all schemas' and users'
build.sbt. I think it's either
https://issues.apache.org/jira/browse/DAFFODIL-1679 or another issue. Having
the plugin would make changing module names less disruptive even after 4.0.0
comes out.
Changing daffodil-runtime2's module name won't affect any schemas or users, however, so it's fine
to rename it now. I'm fine with "daffodil-codegen-c" or even "codegen-c" if
anyone else thinks we should drop the daffodil- prefix completely. Let's hear more opinions.
John
-----Original Message-----
From: Mike Beckerle <[email protected]>
Sent: Friday, February 3, 2023 3:03 PM
To: [email protected]
Subject: EXT: Re: Rename daffodil-runtime2 to daffodil-generator-c
I suggest "codegen-c" as the name and convention.
I don't think the daffodil- prefix helps really and just makes all the names
long.
(Somewhere we had a discussion of eliminating all the daffodil- prefixes.
Can't recall why we didn't. )
On Fri, Feb 3, 2023 at 5:31 PM Interrante, John A (GE Research, US) <
[email protected]> wrote:
Eventually Daffodil will support multiple code generators. I have
already sent a pull request to generalize Daffodil's CLI so we can
call "daffodil generate <lang>" for additional languages. Now I want
to discuss renaming daffodil-runtime2's module, package, and class
names to new names that are more similar to and yet distinguishable from other
code generators'
modules, packages, and classes.
Daffodil's developers envisioned that Daffodil would have multiple
backends/runtimes so they used "runtime2" as a placeholder name for
whatever the next backend would be. That turned out to be a C code
generator, but we still named it "daffodil-runtime2" and used "[Rr]untime2"
in many places within it. However, the use of "runtime2" as a name
has to stop if we want Daffodil to generate code for additional
languages. We can't have "runtime2", "runtime3", etc., since users
will have no idea which runtimes correspond to which languages.
As I see it, there are two choices for the C code generator's new
module name. We can say 1) daffodil-c-generator or we can say 2)
daffodil-generator-c, that is, "daffodil-<language>-generator" or
"daffodil-generator-<language>". I originally was going to say
daffodil-c-generator like how I say "Daffodil's C code generator" in
English but I've rethought that and realized that
daffodil-generator-<language> will group multiple code generators
together, encouraging developers to update them together and
eventually move any common code/TDML tests to "daffodil-generator".
If developers agree, I'll start work on the necessary
module/package/class/wiki changes and send a pull request (after the
OSGi refactoring if it's going to be merged very soon).
John
