+1 to daffodil-codegen-c (and daffodil-codegen for any common classes/schemas/TDML used by multiple codegens).
I agree there's no need to discuss renaming anything else except daffodil-runtime2 at this time, although I agree with Steve about 1) finding some other way to separate code and infrastructure directories if we drop "daffodil-", and 2) keeping the jar names the same through sbt configuration (yay for backward compatibility). I've added these good points to https://issues.apache.org/jira/browse/DAFFODIL-2406. Davin, we have only one CLI and it's called "daffodil". We use "daffodil generate c -s <schema>" to invoke the C code generator which creates a "c" subdirectory in the current directory. Once you run "make" in that subdirectory, you do get a "c/daffodil" executable with its own parse and unparse subcommands similar to Daffodil's CLI. John -----Original Message----- From: Steve Lawrence <slawre...@apache.org> Sent: Monday, February 6, 2023 5:37 AM To: dev@daffodil.apache.org Subject: EXT: Re: Rename daffodil-runtime2 to daffodil-generator-c +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 <mbecke...@apache.org> > Sent: Friday, February 3, 2023 3:03 PM > To: dev@daffodil.apache.org > 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) < > john.interra...@ge.com> 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
