emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Project out of sources compilation


From: Konstantin Kharlamov
Subject: Re: [PATCH] Project out of sources compilation
Date: Wed, 03 Apr 2024 18:00:28 +0300
User-agent: Evolution 3.52.0

On Wed, 2024-04-03 at 17:11 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > Cc: rms@gnu.org, spacibba@aol.com, dmitry@gutov.dev,
> > emacs-devel@gnu.org
> > Date: Wed, 03 Apr 2024 16:31:30 +0300
> > 
> > On Wed, 2024-04-03 at 14:45 +0300, Eli Zaretskii wrote:
> > > > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > > > Cc: dmitry@gutov.dev, emacs-devel@gnu.org
> > > > Date: Wed, 03 Apr 2024 13:40:59 +0300
> > > > 
> > > > 1: Emacs does not fully support it though, because while object
> > > > files
> > > > and configs do end up inside `build`, however `*.elc` files are
> > > > still
> > > > scattered all over the repo. But I hope you get the idea.
> > > 
> > > The *.elc files are considered part of the source tree (they are
> > > in
> > > the release tarball, and are portable, so no need to rebuild them
> > > when
> > > changing some configuration options).  
> > 
> > They are generated during compilation and are not commited into
> > git. 
> > That makes them build artifacts.
> 
> How is this relevant to whether or not Emacs supports out of tree
> builds? 

Directly: the point of "out of tree build" is encapsulating build
artifacts in the build dir.  I'm pointing out that Emacs has build
artifacts being put outside build dir, hence the "out of tree build" 
workflow is not working as expected.

>  Building from Git is a special kind of activity; it has its
> own INSTALL file and _must_ build some of the files in the source
> tree.  Are you aware of many projects whose build from Git can be
> done
> without first populating the source tree with some files?

Most existing active projects 😊  Most that were using autotools/make
has migrated to Meson.  That includes active freedesktop projects
(Mesa, Xorg, libinput, Pulseaudio, etc), Gnome projects, i3wm, Compton
after it became Picom, all active Enlightenment projects…  The list
goes on and on.  Meson drastically reduces maintainance burden but it's
a separate story.  What matters is that Meson by design works with out
of tree builds.  It is possible to hack in generating files in the
tree, but it's frowned upon for many reasons.

Then you have CMake projects, which I think has always supported out of
tree build without creating any config files whatsoever outside?
Offhand that includes all KDE projects.

Lastly, you have autotools projects where `configure` file is not
generated 😊 `fio` is one example (although admittedly I didn't test
out of tree build in there, but clearly if you have `configure` as part
of the codebase, then you don't have to generate it in the tree).

>   Heck, you
> don't even have the configure script when you clone the repository,
> and out-of-tree build works by invoking the configure script from a
> directory _other_ than the one where the script lives.  Right?

Good point.  That's yet another reason "out of tree build" workflow
isn't fully supported.  I just didn't think about it because didn't
have problems with that, but you are correct here.

> > The fact they're distributed in release tarballs does not make it
> > less true.  Distributing them in tarballs is not strictly
> > necessary,
> > exactly because they can be generated by anyone.
> 
> Not true.

Well, admittedly I didn't try building from release tarball.  But if it
lacks some code to re-create `.elc` files, that's a bug.  I can explain
why if you're interested.

> > Having .elc files in the source tree results in problems when a
> > user
> > created a dir `build-feature1` for one feature branch, and a dir
> > `build-feature2` for another; and then `build-feature1` somehow
> > ends up
> > having "feature2".  Which is because it's using build artifacts
> > that
> > are outside `build-feature1`.
> 
> Again, not relevant to the aspect on which I commented.

Fair enough.  I was just pointing out why "out of tree builds" should
work the way they don't in Emacs right now.  But yeah, if you already
understand that, I guess my explanation on that is unnecessary.

> > Thus, Emacs certainly does not fully support "out of tree" builds.
> 
> It does.  You are just talking about a very different kind of "out of
> tree build".

Well… There does not exist strict definition for "out of tree build"
that I can point you to, so that risks becoming a philosophical debate.

To understand what that means you need to understand what it solves. 
Which you seem to understand already per the previous paragraph, so I
can only add that "partial out of tree build" still has problems that
"full out of tree build" solves.

So there is only one kind of "out of tree build", the "full" one. The
"partial" one should be explicitly specified as being only partial,
whereas saying "out of tree build" without any prefix implies it is a
"full" one.

I hope now you understand why I'm saying Emacs doesn't fully support it
😊



reply via email to

[Prev in Thread] Current Thread [Next in Thread]