All things being equal, I prefer "daffodil-codegen-c" and the scheme
`daffodil-codegen-<lang>`. I prefer the longer, descriptive name and if it
annoys me on the CLI, I'll just create an alias for it (developers do this all
the time, so this is not a stretch or hardship). The longer name allows it to
be installed into say `/usr/bin` without fears of colliding with other
executables in the same directory or in the same `PATH`. I also like it when
the suite of tools "group together" in a directory listing (e.g.,
`daffodil-*`). It helps when I haven't used a tool in a while, I have a better
chance of finding it if they are prefixed in this manner.
Another option would be to have a single code generation tool called
"daffodil-codegen" and the language is provided as an argument (e.g.,
daffodil-codegen <lang>, or -l <lang>). I imagine the interface for these
various generators to use similar kinds of options and consolidating the
argument parsing can be helpful for the user and the developer. It also eases
the installation as the installation code doesn't need to change as new
languages are added. Could also make the testing code more concise. The down
side is that it is slightly more difficult to determine the languages that are
supported as they are not embedded in the filename as they would be with the
daffodil-codegen-<lang>` scheme, so the user would need to either query the
tool for the languages supported or look it up in the manual for the version
installed.
Hope it helps,
Davin
On 2/3/23, 8:12 PM, "Interrante, John A (GE Research, US)"
<john.interra...@ge.com> 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
-----------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may contain
company proprietary information. If you are not the intended
recipient, notify the sender immediately and delete this
message. Publication, reproduction, forwarding, or content
disclosure is prohibited without the consent of the original
sender and may be unlawful.
Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
-----------------------------------------------------------------
