This is a multi-part message in MIME format.
--nextPart2145921.OBFZWjSADL
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
On Sonntag, 28. April 2024 12:50:06 CEST Albert Astals Cid wrote:
> El divendres, 19 d=E2=80=99abril del 2024, a les 11:17:09 (CEST), Anna (c=
ybertailor)
> Vyalkova va escriure:
> > Hi,
> >=20
> > I'd like to develop Nim applications (with possible GUI support via
> > nimqt) but this language lacks support for any standard build system.
> >=20
> > So that's the thing I'm focused on right now (just happened to also be
> > my favorite thing).
> >=20
> > Alternatives I considered:
> >=20
> > 1. Procedure described in "CMakeAddNewLanguage.txt". First of all,
> > that's scary and second it doesn't cover my use case: Nim is not a
> > compiler but rather a transpiler. It compiles Nim code into C/C++/JS
> > code and then calls system compiler to get native binaries. These steps
> > could be separated.
> >=20
> > 2. Going with my own "nim-for-cmake" module library. That's possible but
> > requires lots of boilerplate code that can be avoided if these modules
> > become part of ECM.
> >=20
> > I've implemented an alternative build system for Nim's "nimble" packages
> > before so I know the necessary steps: 1) find the compiler, 2) find the
> > deps, 3) generate a json-script, 4) extract the depfiles, 5) execute the
> > script.
> >=20
> > Can I start making such ECM module or should it be a separate CMake
> > module library?
>=20
> You will probably find more people that know about ECM in kde frameworks
> devel mailing list than here, this list is nowadays pretty dormant.
>=20
> My suggetsion would be, talk to the cmake folks, they are a relatively op=
en
> bunch of people that like their build system to support as many things
> possible and what you really want is to have support in cmake itself, not
> having to include some extra stuff to make it work.
yes, right here, probably the "Development" channel:
https://discourse.cmake.org/[1]
Alex
=2D-------
[1] https://discourse.cmake.org/
--nextPart2145921.OBFZWjSADL
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"
On Sonntag, 28. April 2024 12:50:06 CEST Albert Astals Cid wrote:
>=
; El divendres, 19 d=E2=80=99abril del 2024, a les 11:17:09 (CEST), Anna (c=
ybertailor)
>=
; Vyalkova va escriure:
>=
; > Hi,
>=
; >
>=
; > I'd like to develop Nim applications (with possible GUI support via<=
/p>
>=
; > nimqt) but this language lacks support for any standard build system=
=2E
>=
; >
>=
; > So that's the thing I'm focused on right now (just happened to also =
be
>=
; > my favorite thing).
>=
; >
>=
; > Alternatives I considered:
>=
; >
>=
; > 1. Procedure described in "CMakeAddNewLanguage.txt". First=
of all,
>=
; > that's scary and second it doesn't cover my use case: Nim is not a
>=
; > compiler but rather a transpiler. It compiles Nim code into C/C++/JS=
>=
; > code and then calls system compiler to get native binaries. These st=
eps
>=
; > could be separated.
>=
; >
>=
; > 2. Going with my own "nim-for-cmake" module library. That'=
s possible but
>=
; > requires lots of boilerplate code that can be avoided if these modul=
es
>=
; > become part of ECM.
>=
; >
>=
; > I've implemented an alternative build system for Nim's "nimble&=
quot; packages
>=
; > before so I know the necessary steps: 1) find the compiler, 2) find =
the
>=
; > deps, 3) generate a json-script, 4) extract the depfiles, 5) execute=
the
>=
; > script.
>=
; >
>=
; > Can I start making such ECM module or should it be a separate CMake<=
/p>
>=
; > module library?
>=
;
>=
; You will probably find more people that know about ECM in kde frameworks<=
/p>
>=
; devel mailing list than here, this list is nowadays pretty dormant.
>=
;
>=
; My suggetsion would be, talk to the cmake folks, they are a relatively op=
en
>=
; bunch of people that like their build system to support as many things
>=
; possible and what you really want is to have support in cmake itself, not=
>=
; having to include some extra stuff to make it work.
yes, right here, probably the "Development" channel:
https://discourse.cmake.org/
Alex
--nextPart2145921.OBFZWjSADL--