all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rms@gnu.org, spacibba@aol.com, dmitry@gutov.dev, emacs-devel@gnu.org
Subject: Re: [PATCH] Project out of sources compilation
Date: Wed, 03 Apr 2024 18:00:28 +0300	[thread overview]
Message-ID: <c859b3fa70eec559050d7377e759b8f262abb520.camel@yandex.ru> (raw)
In-Reply-To: <86sf028rjo.fsf@gnu.org>

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	other threads:[~2024-04-03 15:00 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4wwljrdnra3bsloehioa46y24ozxajajmvf2elvskxxq3mhtg2.ref@pyv2z5snot6h>
2024-03-16 13:12 ` Project out of sources compilation Ergus
2024-03-16 16:50   ` Konstantin Kharlamov
2024-03-16 19:00     ` Ergus
2024-03-16 20:56       ` Konstantin Kharlamov
2024-03-17  2:53   ` Dmitry Gutov
2024-03-17  7:22     ` Ergus
2024-03-17  8:45       ` Eli Zaretskii
2024-03-17 17:33         ` Ergus
2024-03-17 17:38           ` Eli Zaretskii
2024-03-17 17:58             ` Ergus
2024-03-17 11:36   ` Augusto Stoffel
2024-03-17 17:47     ` Ergus
2024-03-19 18:36       ` Ergus
2024-03-27 16:38         ` [PATCH] " Ergus
2024-03-31  2:41           ` Dmitry Gutov
2024-03-31 21:07             ` Ergus
2024-04-01  7:49               ` Dirk-Jan C. Binnema
2024-04-01 13:52                 ` Ergus
2024-04-01 15:09                   ` Dirk-Jan C. Binnema
2024-04-01 17:18                     ` Ergus
2024-04-02 23:23                   ` Dmitry Gutov
2024-04-03 19:47                     ` Ergus
2024-04-06  2:05                     ` Ergus
2024-04-14  1:44                       ` Dmitry Gutov
2024-04-16 14:56                         ` Ergus
2024-04-22 17:05                         ` Ergus
2024-04-22 18:48                           ` Ergus
2024-04-22 21:20                             ` Mohsin Kaleem
2024-04-23 15:17                               ` Ergus
2024-04-23 19:26                                 ` Mohsin Kaleem
2024-04-26  0:47                               ` Dmitry Gutov
2024-04-02 21:39               ` Richard Stallman
2024-04-02 22:43                 ` Dr. Arne Babenhauserheide
2024-04-05 21:40                   ` Richard Stallman
2024-04-03 10:40                 ` Konstantin Kharlamov
2024-04-03 11:45                   ` Eli Zaretskii
2024-04-03 13:31                     ` Konstantin Kharlamov
2024-04-03 14:11                       ` Eli Zaretskii
2024-04-03 15:00                         ` Konstantin Kharlamov [this message]
2024-04-03 15:47                           ` Eli Zaretskii
2024-04-03 17:27                             ` Konstantin Kharlamov
2024-04-03 18:22                               ` Eli Zaretskii
2024-04-03 19:08                                 ` Konstantin Kharlamov
2024-04-03 20:12                                   ` Ergus
2024-04-04  5:26                                     ` Eli Zaretskii
2024-04-04  9:59                                       ` Ergus
2024-04-04 11:59                                         ` Eli Zaretskii
2024-04-04 12:34                                           ` Ergus
2024-04-04 13:02                                             ` Eli Zaretskii
2024-04-04 14:27                                               ` Ergus
2024-04-04 14:41                                                 ` Eli Zaretskii
2024-04-04 18:15                                                   ` Ergus
2024-04-04 18:56                                                     ` Eli Zaretskii
2024-04-04 20:16                                                   ` Konstantin Kharlamov
2024-04-05  5:11                                                     ` Eli Zaretskii
2024-04-04  5:07                                   ` Eli Zaretskii
     [not found]                               ` <87jzlefgi9.fsf@dick>
2024-04-03 18:44                                 ` Konstantin Kharlamov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c859b3fa70eec559050d7377e759b8f262abb520.camel@yandex.ru \
    --to=hi-angel@yandex.ru \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    --cc=spacibba@aol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.