3 ms·

> Once you try to build anything beyond a toy, it quickly becomes chaos. Of course the chaos is not caused by, "very hypotheticaly" let's say, a compiler or ma

> Once you try to build anything beyond a toy, it quickly becomes chaos. Of course the chaos is not caused by, "very hypotheticaly" let's say, a compiler or maybe a language without modules. How would you estimate that ? 20%, 40%, or 70%, true ?

tomjen3 2y ago
Not OP, but its not just that C/C++ lacks modules. I think that is missing the real issue. Any complicated program probably needs a custom developed tool to build it. As a simple example, imagine a program that uses a database - you want to keep the sources as SQL and generate classes from them. Thats a custom build step. Its just that in some languages and build systems (Node, Maven), we have abstracted this away by calling them plugins and they probably come from the same group that made the library you need. No such pluginsystem exists, as far as I am aware, for makefiles.
ReleaseCandidat 2y ago
Good luck writing Makefiles for Fortran, OCaml or (whenever they will really, actually work) C++ modules. There aren't many widely used build systems that can handle such dynamic dependencies without some special "magic" for these, the only one that I know of (with a significant number of users, so not Shake) is Buck 2 (Bazel and all C++ build systems use "special magic", you can't write in user rules).
- instig007 2y ago
  > Good luck writing Makefiles for OCaml So what's the problem exactly? https://mmottl.github.io/ocaml-makefile/ https://mmottl.github.io/ocaml-makefile/ Oh look, it even builds a project faster than Dune: https://discuss.ocaml.org/t/dune-build-vs-makefile/11394 https://discuss.ocaml.org/t/dune-build-vs-makefile/11394
  - ReleaseCandidat 2y ago
    > So what's the problem exactly? They all have the samé problem: that you don't know the name (or even the number) of modules (module files) being generated without reading the source. And as a bonus every compiler uses a sligthly different naming scheme for the generated module file (this is of course no problem for OCaml ;). As an example (using Fortran). File `test.f90`: module first contains subroutine hello () end subroutine hello end module first module second contains subroutine world () end subroutine world end module second `gfortran -c test.f90` yields the following files (2 of them are modules): -rw-r--r-- 1 roland staff 221 Sep 21 19:07 first.mod -rw-r--r-- 1 roland staff 225 Sep 21 19:07 second.mod -rw-r--r-- 1 roland staff 185 Sep 21 19:07 test.f90 -rw-r--r-- 1 roland staff 672 Sep 21 19:08 test.o
- overanalytcl 2y ago
  > Good luck writing Makefiles for Fortran, OCaml or (whenever they will really, actually work) C++ modules. I've successfully written Makefiles for Fortran and they worked with ifort/ifx and gfort. In my experiments I've also made GNU Cobol, GNU Modula-2 and Vishap Oberon fit within the Makefile paradigm without much trouble. You have failed to provide reasons as to why those languages in particular (or more likely any language that's not of C heritage) can't be used with Makefiles. For instance, you can definitely couple OCaml with Makefiles, just use ocamlopt and treat .cmx files as object files, generated beforehand by ocamlopt -c (like you'd do with GCC). I am not familiar with C++ modules and as such I didn't experiment with them.
  - ReleaseCandidat 2y ago
    > I've successfully written Makefiles for Fortran and they worked with ifort/ifx and gfort. Did the samé (I'm not sure if gfortran did exist at all at the time, I guess it had been g95), plus they worked with Absoft, PGI and Pathscale too (yes, that has been some time ago). And it was a great PITA. Not the least because at the time no Fortran compiler did generate the dependency description, so you either had to parse the Fortran sources by yourself or use makedepf90, which didn't work with all sources. > You have failed to provide reasons as to why those languages in particular [...] can't be used with Makefiles. I have obviously badly worded that. I didn't mean it is impossible, just that is a great PITA. > I am not familiar with C++ modules and as such I didn't experiment with them. They have the same problem, you don't know the name of the module that is going to be produced.
- alextingle 2y ago
  I've written Makefile for FORTRAN. Dealing with modules added about 6 extra lines. That was one of the more complex rules. Does that count as "special magic"?
  - ReleaseCandidat 2y ago
    If you've got your rule working for arbitrary named (i.e. not the name of the file) modules and submodules and an arbitrary number of modules and submodules generated by a single source file which uses FPP (whatever program that actually is ;) or CPP as preprocessor, then yes. And with "working" I mean adding each module file as a single target which is able to trigger a rebuild of the module. You should be able to get that to work easier with GNU Make 4.3 and later, as that now supports grouped targets - which I have learned elsewhere in this forum. Now the only problém is getting your module dependencies without first compiling all files to generate the modules, as `gfortran -M` (and any other compiler that generates dependency information) AFAIK still doesn't "know" which file produces which module without actually generating the module files.
kaba0 2y ago
There are projects that generate files, depend on multiple languages, etc. If you push the job of a build tool to the compiler infrastructure, then why even have a “build tool” in the first place? Make is simply anemic for anything remotely complex, and there are countless better tools that actually solve the problem.
- imtringued 2y ago
  Yeah my biggest problem with make is that the compiler has to generate the header file dependencies. This means starting a C or C++ project with make from scratch is a hard problem and there is no default solution or default file for this other than to just use CMake.

tomjen3 2y ago

Not OP, but its not just that C/C++ lacks modules. I think that is missing the real issue. Any complicated program probably needs a custom developed tool to build it. As a simple example, imagine a program that uses a database - you want to keep the sources as SQL and generate classes from them. Thats a custom build step. Its just that in some languages and build systems (Node, Maven), we have abstracted this away by calling them plugins and they probably come from the same group that made the library you need. No such pluginsystem exists, as far as I am aware, for makefiles.

ReleaseCandidat 2y ago

Good luck writing Makefiles for Fortran, OCaml or (whenever they will really, actually work) C++ modules. There aren't many widely used build systems that can handle such dynamic dependencies without some special "magic" for these, the only one that I know of (with a significant number of users, so not Shake) is Buck 2 (Bazel and all C++ build systems use "special magic", you can't write in user rules).

instig007 2y ago
> Good luck writing Makefiles for OCaml So what's the problem exactly? https://mmottl.github.io/ocaml-makefile/ https://mmottl.github.io/ocaml-makefile/ Oh look, it even builds a project faster than Dune: https://discuss.ocaml.org/t/dune-build-vs-makefile/11394 https://discuss.ocaml.org/t/dune-build-vs-makefile/11394
- ReleaseCandidat 2y ago
  > So what's the problem exactly? They all have the samé problem: that you don't know the name (or even the number) of modules (module files) being generated without reading the source. And as a bonus every compiler uses a sligthly different naming scheme for the generated module file (this is of course no problem for OCaml ;). As an example (using Fortran). File `test.f90`: module first contains subroutine hello () end subroutine hello end module first module second contains subroutine world () end subroutine world end module second `gfortran -c test.f90` yields the following files (2 of them are modules): -rw-r--r-- 1 roland staff 221 Sep 21 19:07 first.mod -rw-r--r-- 1 roland staff 225 Sep 21 19:07 second.mod -rw-r--r-- 1 roland staff 185 Sep 21 19:07 test.f90 -rw-r--r-- 1 roland staff 672 Sep 21 19:08 test.o
overanalytcl 2y ago
> Good luck writing Makefiles for Fortran, OCaml or (whenever they will really, actually work) C++ modules. I've successfully written Makefiles for Fortran and they worked with ifort/ifx and gfort. In my experiments I've also made GNU Cobol, GNU Modula-2 and Vishap Oberon fit within the Makefile paradigm without much trouble. You have failed to provide reasons as to why those languages in particular (or more likely any language that's not of C heritage) can't be used with Makefiles. For instance, you can definitely couple OCaml with Makefiles, just use ocamlopt and treat .cmx files as object files, generated beforehand by ocamlopt -c (like you'd do with GCC). I am not familiar with C++ modules and as such I didn't experiment with them.
- ReleaseCandidat 2y ago
  > I've successfully written Makefiles for Fortran and they worked with ifort/ifx and gfort. Did the samé (I'm not sure if gfortran did exist at all at the time, I guess it had been g95), plus they worked with Absoft, PGI and Pathscale too (yes, that has been some time ago). And it was a great PITA. Not the least because at the time no Fortran compiler did generate the dependency description, so you either had to parse the Fortran sources by yourself or use makedepf90, which didn't work with all sources. > You have failed to provide reasons as to why those languages in particular [...] can't be used with Makefiles. I have obviously badly worded that. I didn't mean it is impossible, just that is a great PITA. > I am not familiar with C++ modules and as such I didn't experiment with them. They have the same problem, you don't know the name of the module that is going to be produced.
alextingle 2y ago
I've written Makefile for FORTRAN. Dealing with modules added about 6 extra lines. That was one of the more complex rules. Does that count as "special magic"?
- ReleaseCandidat 2y ago
  If you've got your rule working for arbitrary named (i.e. not the name of the file) modules and submodules and an arbitrary number of modules and submodules generated by a single source file which uses FPP (whatever program that actually is ;) or CPP as preprocessor, then yes. And with "working" I mean adding each module file as a single target which is able to trigger a rebuild of the module. You should be able to get that to work easier with GNU Make 4.3 and later, as that now supports grouped targets - which I have learned elsewhere in this forum. Now the only problém is getting your module dependencies without first compiling all files to generate the modules, as `gfortran -M` (and any other compiler that generates dependency information) AFAIK still doesn't "know" which file produces which module without actually generating the module files.

kaba0 2y ago

There are projects that generate files, depend on multiple languages, etc. If you push the job of a build tool to the compiler infrastructure, then why even have a “build tool” in the first place? Make is simply anemic for anything remotely complex, and there are countless better tools that actually solve the problem.

imtringued 2y ago
Yeah my biggest problem with make is that the compiler has to generate the header file dependencies. This means starting a C or C++ project with make from scratch is a hard problem and there is no default solution or default file for this other than to just use CMake.