7 ms·

This readme could use a definition for those of us that don’t know qt creator. Here’s what I think it might be after reading half of this doc. LeanCreator is a

This readme could use a definition for those of us that don’t know qt creator. Here’s what I think it might be after reading half of this doc. LeanCreator is a lean cross-platform integrated development environment (IDE) based on Qt Creator but stripped down to a single file, easy to build, light weight executable with no external dependencies.

Rochus 4y ago
That's one part of the story; LeanCreator is rather "derived from" than "based on" QtCreator, because there was a lot of refactoring and redesign; it's also important to note that it uses the BUSY build system which is fully integrated with the IDE with semantic navigationt through the build specification files (instead of qmake, see https://github.com/rochus-keller/busy); https://github.com/rochus-keller/busy); and with "stripped-down" and "lean" I mean that I kicked out all stuff I never touched during the last twenty years.
- Brian_K_White 4y ago
  "I kicked out all stuff I never touched during the last twenty years." A fine and eminently defensible filter.
- hermitcrab 4y ago
  I've been using qmake for >20 years. Its good enough for my purposes. I have no plan to switch to cmake or any other build system, unless I have to. But I am also using Subversion, so I am not one of the 'cool kids'.
  - Rochus 4y ago
    Same here in principle; the problems start when you have big project which require qmake SUBDIRS and the like; it's ugly and very slow. I'm neither one of the 'cool kids' ;-)
    - hermitcrab 4y ago
      I'm solo developer, so I haven't run into that. Do you mean it is slow to modify a qmake file with subdirs, or slow for qmake to evaluate it?
      - Rochus 4y ago
        You can also easily run into that as a solo developer if you have a project with more than one target, e.g. an application with a few shared libraries (or e.g. Qt plugins). > is slow to modify a qmake file with subdirs, or slow for qmake to evaluate it? It's mostly slow because it generates a lot of make files which all have to be run to find out whether there is anything to do; you can e.g. try by generating the qmake project for LeanQt and open and run it in Qt Creator; then when everything is built make a change in one file and build; when you do the same with LeanCreator and BUSY you will notice that it's more than twenty times faster.
- bitwize 4y ago
  I thought the modern C and C++ communities effectively standardized on CMake? I've never heard of BUSY before this, and I'm dreading the "now there are 14 competing standards" implications.
  - simplotek 4y ago
    > I thought the modern C and C++ communities effectively standardized on CMake? They have. You'll be hard pressed to find anything other than CMake on any professional project. Even Qt has migrated to CMake in spire of having developed make. This was the very first time I ever heard of BUSY, quite frankly.
  - Rochus 4y ago
    I'm no longer interested in cmake or any other dynamically typed build specification language (actually an old-fasioned, string-based scripting language in the case of cmake). I tried to like cmake for twenty years. Now I'm migrating all my projects to BUSY. I'm even leaving qmake behind because it essentially suffers from the same disadvantages than cmake. GN is a much superior build system (or meta build system, if you insist), but unfortunately it is also dynamically typed using glorified strings for all kinds of semantically significant stuff. I want to be able to statically check my build specification and profit of 60 years of programming language best practices, not to guess around and waste time with a specification language suitable for toy projects if at all. BUSY is not yet a standard, but it has the potential. There is enough room in the world for different standards on the same topic.
    - elcritch 4y ago
      Oh cmake is full of so many gotchas. Dynamically typed specification languages are so painful. BUSY looks cool! Unfortunately my work projects rely on another big C++ project that has its own meta cmake layer. One thought, it looks like you're quoting a shell string like: ""NAPPGUI_BUILD_DIR=\"" + tostring(root_build_dir) + "\"" That'll break in annoying (possibly insecure) ways and is tedious to write the quotes. Perhaps you could add a 'quotedString' proc? Maybe: ""NAPPGUI_BUILD_DIR=" + quotedStr(root_build_dir) Speaking of standards, have you tried talking with any cmake collaborators? I recall reading a post on HN discussing a possible new cmake frontend language. Something like BUSY as a frontend could be cool. BTW, here's my latest attempt to avoid dynamic configuration files by making a YAML like in Nim: https://github.com/elcritch/cimporter/blob/exper-interp/tests/rcutils_cimport.nim https://github.com/elcritch/cimporter/blob/exper-interp/test... It may look a bit complicated at first, but the underlying syntax rules are surprisingly simple and consistent. There are only a few small macros for convenience like the 'list' one that replaces array syntax. Best of all that means I get all the goodies of a statically typed language like type annotations from the LSP.
hummus_bae 4y ago
[dead]

Rochus 4y ago

That's one part of the story; LeanCreator is rather "derived from" than "based on" QtCreator, because there was a lot of refactoring and redesign; it's also important to note that it uses the BUSY build system which is fully integrated with the IDE with semantic navigationt through the build specification files (instead of qmake, see https://github.com/rochus-keller/busy); https://github.com/rochus-keller/busy); and with "stripped-down" and "lean" I mean that I kicked out all stuff I never touched during the last twenty years.

Brian_K_White 4y ago
"I kicked out all stuff I never touched during the last twenty years." A fine and eminently defensible filter.
hermitcrab 4y ago
I've been using qmake for >20 years. Its good enough for my purposes. I have no plan to switch to cmake or any other build system, unless I have to. But I am also using Subversion, so I am not one of the 'cool kids'.
- Rochus 4y ago
  Same here in principle; the problems start when you have big project which require qmake SUBDIRS and the like; it's ugly and very slow. I'm neither one of the 'cool kids' ;-)
  - hermitcrab 4y ago
    I'm solo developer, so I haven't run into that. Do you mean it is slow to modify a qmake file with subdirs, or slow for qmake to evaluate it?
    - Rochus 4y ago
      You can also easily run into that as a solo developer if you have a project with more than one target, e.g. an application with a few shared libraries (or e.g. Qt plugins). > is slow to modify a qmake file with subdirs, or slow for qmake to evaluate it? It's mostly slow because it generates a lot of make files which all have to be run to find out whether there is anything to do; you can e.g. try by generating the qmake project for LeanQt and open and run it in Qt Creator; then when everything is built make a change in one file and build; when you do the same with LeanCreator and BUSY you will notice that it's more than twenty times faster.
bitwize 4y ago
I thought the modern C and C++ communities effectively standardized on CMake? I've never heard of BUSY before this, and I'm dreading the "now there are 14 competing standards" implications.
- simplotek 4y ago
  > I thought the modern C and C++ communities effectively standardized on CMake? They have. You'll be hard pressed to find anything other than CMake on any professional project. Even Qt has migrated to CMake in spire of having developed make. This was the very first time I ever heard of BUSY, quite frankly.
- Rochus 4y ago
  I'm no longer interested in cmake or any other dynamically typed build specification language (actually an old-fasioned, string-based scripting language in the case of cmake). I tried to like cmake for twenty years. Now I'm migrating all my projects to BUSY. I'm even leaving qmake behind because it essentially suffers from the same disadvantages than cmake. GN is a much superior build system (or meta build system, if you insist), but unfortunately it is also dynamically typed using glorified strings for all kinds of semantically significant stuff. I want to be able to statically check my build specification and profit of 60 years of programming language best practices, not to guess around and waste time with a specification language suitable for toy projects if at all. BUSY is not yet a standard, but it has the potential. There is enough room in the world for different standards on the same topic.
  - elcritch 4y ago
    Oh cmake is full of so many gotchas. Dynamically typed specification languages are so painful. BUSY looks cool! Unfortunately my work projects rely on another big C++ project that has its own meta cmake layer. One thought, it looks like you're quoting a shell string like: ""NAPPGUI_BUILD_DIR=\"" + tostring(root_build_dir) + "\"" That'll break in annoying (possibly insecure) ways and is tedious to write the quotes. Perhaps you could add a 'quotedString' proc? Maybe: ""NAPPGUI_BUILD_DIR=" + quotedStr(root_build_dir) Speaking of standards, have you tried talking with any cmake collaborators? I recall reading a post on HN discussing a possible new cmake frontend language. Something like BUSY as a frontend could be cool. BTW, here's my latest attempt to avoid dynamic configuration files by making a YAML like in Nim: https://github.com/elcritch/cimporter/blob/exper-interp/tests/rcutils_cimport.nim https://github.com/elcritch/cimporter/blob/exper-interp/test... It may look a bit complicated at first, but the underlying syntax rules are surprisingly simple and consistent. There are only a few small macros for convenience like the 'list' one that replaces array syntax. Best of all that means I get all the goodies of a statically typed language like type annotations from the LSP.

hummus_bae 4y ago

[dead]