On Sun, 06 Feb 2022, Maxime Devos <maximede...@telenet.be> wrote: > Olivier Dion schreef op zo 06-02-2022 om 17:05 [-0500]: >> > Is it restricted to Makefiles, or can it also be used without >> > generating Makefiles? If not, things like progress bars should be >> > easy >> > to implement and file names containing spaces or ‘special >> > characters’ >> > can be used without any problems. >> >> Since it's glued to my project, and since I'm very familiar with >> Makefiles, it only support Makefiles for now. What would be the >> other >> targets you have in mind? > > I was thinking of something like > > $ cd ~/the-source-code > # (I haven't looked much yet, possibly the CLI needs to be very > different) > $ cbuild make --target=aarch64-linux-gnu --prefix=/foo/bar > $ cbuild install --staged-install=/blah
I'm not a fan of configuration with CLI like `--prefix`. I like to have a configuration file that is configurable like so: .config.scm: ----------------------- '((TARGET . aarch64) (PREFIX . /foor/bar)) ----------------------- > Basically, don't delegate to 'make' or 'ninja' or whatever, just build > it. I agree. In the end `make` is only there for tracking dependencies, which can be done easily in Guile I guess. Although, there might be performance problems at large scale, but I don't think I'm there yet ;-) > That's way less portable than 'make' of course, but people that don't > have 'cbuild' or don't want to learn 'cbuild' can still use the > Makefile. Across distros or OS? For other distros, if the only requirements are Guile and pkg-config then I would say that's quite portabled. As for other OS, I personnaly don't care about them. > I noted that you are using #nil in some places. > #nil (an amalgation of #false and the empty list ()) is mostly an > implementation detail for Emacs Lisp support, and not something that > needs to be used in pure Guile. I would use '() instead; it's > also more portable to other Schemes. I did not know that '() was more portable! I did find out that #nil has some problem during syntaxes expansion though. I will change this in my style! > There's also some potential reproducibility problems: in > https://gitlab.com/oldiob/cbuild/-/blob/master/config.scm#L19, > D1CACHE_LINE_SIZE is set based on the cache size where it was > compiled, instead of the cache size where it is supposed to run on. This is true. Fortunately, on a good amount of architectures, L1 cache is 64 bytes. The only way I can see to fix this is to override the configuration in `.config.scm` if compiling for another system. It's not possible to do this at runtime, because I use it for some struct alignments of static variables. -- Olivier Dion Polymtl
