[Debian-lego-team] NQC packaging and upstream change

[Nicolas Schodet]

Hello Matthew,

* Matthew Sheets <mesheets at hotmail.com> [2025-04-25 01:48]:
> > What is the license of the files under emscripten directory, are
> > they also covered by the MPL?
> Yes, the maehw/WebNQC project was itself a fork of BrickBot/NQC, and
> it continued under the MPL in that fork. [...]

OK, good.

> > I notice that there is no way to run the install target without
> > building the emscripten version of NQC.
> The "all" dependency on the "install" target appears to be a leftover
> from the original import.  I don't use install that way myself,
> either, and have no issue with removing the "all" dependency from the
> "install" target if that would work for folks here.

You could have the install target depend on "info nqh nub exec".

Actually exec should depend on nqh and nub, but the Makefile does not
make the difference between the cross compiler and the host compiler,
so it would not work for emscripten.

> > Would you consider making a release?
> If all looks stable after we get the install target straightened out,
> I would certainly be willing do so.  One thing I haven't been sure of
> is how to appropriately version a release that is picking up where a
> dormant upstream left off.  A version 4.0 would clearly and distinctly
> delineate the point of the project transition, while a version 3.2
> might be closer to what semantic versioning practices would dictate
> based on functional changes.  I don't think a reset to 1.0 would fit
> here, either from a project standpoint or a packaging standpoint.  (I
> can say, though, that I am not planning to continue the "-r" suffix
> scheme.)  I'm currently leaning towards a 4.0 for delineation clarity
> but would welcome any thoughts.

4.0 would be ok, it’s more clear that there is almost 20 years since the
last version :)

Side note: there are v3.1-r6 and v3.1-r4 tags in the repository, but
they do not correspond to those versions.

Thanks,

Nicolas.