On Thu, Sep 21, 2023 at 5:03 PM Dave Blanchard wrote:
> I attached an example script which one could use to bootstrap cmake in a
> LFS type environment during the initial tool build, or pick and choose the
> necessary bits in order to bootstrap a custom cmake on their own live
>running system.
On Thu, Sep 21, 2023 at 5:03 PM Dave Blanchard wrote:
> I attached an example script which one could use to bootstrap cmake in a
> LFS type environment during the initial tool build, or pick and choose the
> necessary bits in order to bootstrap a custom cmake on their own live
>running system.
On Fri, 22 Sep 2023 17:08:15 +0200
Mattias Andrée wrote:
Dear Mattias,
> You can used make to run ./configure automatically, all you need to
> do is simply rename Makefile to makefile.in, let ./configure run `ln
> -s makefile.in makefile` and create a new file named Makefile
> containing:
>
>
Hi,
On Fri, Sep 22, 2023 at 05:08:15PM +0200, Mattias Andrée wrote:
>
> You can used make to run ./configure automatically, all you need to do is
> simply
> rename Makefile to makefile.in, let ./configure run `ln -s makefile.in
> makefile`
> and create a new file named Makefile containing:
>
NRK writes:
> On Fri, Sep 22, 2023 at 04:07:15PM +0200, Roberto E. Vargas Caballero wrote:
> > can you explain me how you solve the problem of duplicated static
> > symbols?
>
> It's not as big of a problem you're making it out to be. Neither dwm or
> st for example has duplicated static symbols.
On Fri, 22 Sep 2023 15:54:59 +0200
Laslo Hunhold wrote:
> On Thu, 21 Sep 2023 16:05:17 +0200
> David Demelier wrote:
>
> Dear David,
>
> > It's near to impossible to convert a CMake project to make
> > automatically, CMake is almost like a scripting language given the
> > numerous of things
On Fri, Sep 22, 2023 at 04:07:15PM +0200, Roberto E. Vargas Caballero wrote:
> can you explain me how you solve the problem of duplicated static
> symbols?
It's not as big of a problem you're making it out to be. Neither dwm or
st for example has duplicated static symbols.
And it's easily
On 23/09/22 04:27PM, Страхиња Радић wrote:
> ...according to sloccount[1]...
[1]: https://dwheeler.com/sloccount/
signature.asc
Description: PGP signature
On 23/09/22 07:27PM, NRK wrote:
> And this is no longer the 50s, we have enough memory to build a couple
> thousand line of code without *requiring* splitting things into multiple
> intermediate object files to avoid going OOM (even with bloated
> compilers like gcc/clang with optimization
Hi,
On Fri, Sep 22, 2023 at 07:27:25PM +0600, NRK wrote:
> $ make
> # ... builds st
> $ make CFLAGS="-g3 -fsanitize=address,undefined"
> # ... builds nothing because make doesn't take CFLAGS changes into
> account.
>
> I've seen some (hacky) ways to dump the flags into a
On Fri, Sep 22, 2023 at 12:33:15PM +0200, Roberto E. Vargas Caballero wrote:
> In a Makefile (in a good well written) you only have to pass a
> different CFLAGS value
Either I haven't communicated properly, or people are not reading
clearly. In either case, here's a practical example using a
Hi,
On Fri, Sep 22, 2023 at 04:06:25PM +0600, NRK wrote:
> On Fri, Sep 22, 2023 at 11:18:47AM +0200, Страхиња Радић wrote:
> > ./build.sh
>
> But in short: you simply include any `.c` file into one. There's zero
and then you get name collisions because all the static symbols are
compiled in a
On Fri, Sep 22, 2023 at 11:18:47AM +0200, Страхиња Радић wrote:
> ./build.sh
I did not advocate for `build.sh`.
And the wikipedia article I linked explains how unity-builds works
pretty well already: https://en.wikipedia.org/wiki/Unity_build
But in short: you simply include any `.c` file into
On 23/09/22 03:09PM, NRK wrote:
> Some tend to argue that this "doesn't scale", but as I said, this is for
> small projects. And the chances of your small project turning into the
> next linux kernel [2] with 30M LoC is probably not high. So don't create
> new *actual problems* by trying to solve
On Fri, Sep 22, 2023 at 10:00:56AM +0200, Страхиња Радић wrote:
> How does it decide when rebuilding is needed? Does it track dependencies and
> how?
IMO in small projects, these are problems that should be *avoided entirely*
instead of creating them and then solving it. E.g you can have a
On 23/09/22 10:26AM, Sagar Acharya wrote:
> You can have inputs like
>
> ./build.dash rebuild
>
> which first cleans earlier compiled files and builds.
All of the build systems I listed support cleaning and rebuilding as well.
> Dependencies would go into logic of shell script, it can have
You can have inputs like
./build.dash rebuild
which first cleans earlier compiled files and builds.
Dependencies would go into logic of shell script, it can have
check_dependencies which checks for files. Normally as you code a shell script!
Thanking you
Sagar Acharya
On 23/09/22 09:50AM, Sagar Acharya wrote:
> A better way to build is to write a build.dash script
Some elaboration is needed.
In what way would this shell script be better than the make systems I listed?
How does it decide when rebuilding is needed? Does it track dependencies and
how?
A better way to build is to write a build.dash script
It would simply execute in shell. I use this method. It is extremely readable
and manageable. Ofc, it cannot be used for other softwares where bloatware is
used!
Thanking you
Sagar Acharya
https://humaaraartha.in/selfdost/selfdost.html
On 23/09/21 09:42AM, LM wrote:
> I build a lot of common libraries and programs from source. Many of
> them are switching to cmake. I'm not a fan of cmake. For one thing,
> it's so complicated to build from source code that I can't bootstrap
> the build of cmake itself. I really would prefer
[After re-reading that email I see that I should have edited it bit better
before posting:]
I've used all the mainstream build systems to build thousands of other people's
software packages, and a few of my own, so I have a good idea how they each
stack up from the usability department at
I've used all the mainstream build systems to build thousands of other people's
software packages, and a few of my own, so I have a good idea how they each
stack up from the usability department at least.
All things considered, over the course of building many thousands of packages
with it
Am Thu, Sep 21, 2023 at 04:05:17PM +0200 schrieb David Demelier:
> Hi,
>
> It's near to impossible to convert a CMake project to make
> automatically, CMake is almost like a scripting language given the
> numerous of things you can do with it.
>
> Keep in mind that plain make (POSIX) is enough for
On 2023-09-21 14:42, LM wrote:
I build a lot of common libraries and programs from source. Many of
them are switching to cmake. I'm not a fan of cmake. For one thing,
it's so complicated to build from source code that I can't bootstrap
the build of cmake itself. I really would prefer to
On Thu, 2023-09-21 at 09:42 -0400, LM wrote:
> I build a lot of common libraries and programs from source. Many of
> them are switching to cmake. I'm not a fan of cmake. For one thing,
> it's so complicated to build from source code that I can't bootstrap
> the build of cmake itself. I really
I build a lot of common libraries and programs from source. Many of
them are switching to cmake. I'm not a fan of cmake. For one thing,
it's so complicated to build from source code that I can't bootstrap
the build of cmake itself. I really would prefer to build as many of
my tools from source
26 matches
Mail list logo
