Re: What can we not compile into fluxbox?

Matt Banack <[email protected]> Sun, 1 May 2022 11:56:33 -0500
Newsgroups gmane.comp.window-managers.fluxbox.user
Message-ID <CAEf0pqB_PG+b7=95WpByL_+jAzvYFTcp7puiNwb8B+A6+DTpZA@mail.gmail.com>
--===============5739526601990121669==
Content-Type: multipart/alternative; boundary="000000000000114f2905ddf62939"

--000000000000114f2905ddf62939
Content-Type: text/plain; charset="UTF-8"

Hi Maciej,

With the caveat that I'm a passionate user and haven't contributed anything
to the codebase (yet).  The short answer is no, unless you're willing to
dive into the source and change things.

> Just curious, are the any other things we can not compile into fluxbox
besides what is shown after "./configure --help"?
If you're interested in the internals, you can look at the autoconf file
configure.ac and see how those configure options get mapped to #defines.
Then you can look through the code for things like #ifdef XINERAMA, #ifdef
USE_TOOLBAR.  If you *really* want to slim down your binary as much as
possible, you could look at the config.h defines starting with HAVE_ and
evaluate them individually... if you override the detection for which
things you have available, some of those will compile out code, but some of
them will just take alternate paths.  You will likely be sacrificing
features and/or performance by doing this, but it's up to you to evaluate
them individually.  There is an implicit assumption that no one would ever
want to turn those off, but YMMV.

As far as window managers go, fluxbox is already on the extremely lean
side.  I think you will find that the benefit of not compiling something
like tab support (if you're not using tabs) doesn't get you any real
performance win.

#ifdef can work well for some things that are relatively
self-contained, but usually comes at a cost in code readability.  Tabbing
is central enough to the design of FB that it would be invasive to try to
take it out at compilation -- of course if someone was motivated, it's
possible to go do on a local tree to test the final binary size and compare
performance.  You would end up with a slightly smaller binary, but the
amount of work involved would probably not pay off (and getting it
upstreamed is a separate question).

Matt

On Wed, Apr 20, 2022 at 6:25 AM Maciej M. <[email protected]> wrote:

> Just curious, are the any other things we can not compile into fluxbox
> besides what is shown after "./configure --help"?
>
> For me personally this flexibility is strong attribute of Fluxbox as I do
> not compile in parts I do not need.
>
> Would love not to compile in window tabbing but as far as I know it is not
> possible. Or maybe I am wrong and there is a way? Anyone?
> _______________________________________________
> Fluxbox-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fluxbox-users
>

--000000000000114f2905ddf62939
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Maciej,<div><br></div><div>With the caveat that I&#39;m=
 a passionate user and haven&#39;t contributed anything to the codebase (ye=
t).=C2=A0 The short answer is no, unless you&#39;re willing to dive into th=
e source and change things.</div><div><br></div><div>&gt;=C2=A0<span style=
=3D"color:rgb(0,0,0)">Just curious, are the any other things we can not com=
pile into fluxbox besides what is shown after &quot;./configure --help&quot=
;?</span></div><div>If you&#39;re interested in the internals, you can look=
 at the autoconf file <a href=3D"http://configure.ac">configure.ac</a> and =
see how those configure options get mapped to #defines.=C2=A0 Then you can =
look through the code for things like #ifdef XINERAMA, #ifdef USE_TOOLBAR.=
=C2=A0 If you *really* want to slim down your binary as much as possible, y=
ou could look at the config.h defines starting with HAVE_ and evaluate them=
 individually... if you override the detection for which things you have av=
ailable, some of those will compile out code, but some of them will just ta=
ke alternate paths.=C2=A0 You will likely be sacrificing features and/or pe=
rformance by doing this, but it&#39;s up to you to evaluate them individual=
ly.=C2=A0 There is an implicit assumption that no one would ever want to tu=
rn those off, but YMMV.</div><div><br></div><div>As far as window managers =
go, fluxbox is already on the extremely lean side.=C2=A0 I think you will f=
ind that the benefit of not compiling something like tab support (if you&#3=
9;re not using tabs) doesn&#39;t get you any real performance win.</div><di=
v><br></div><div>#ifdef can work well for some things that are relatively s=
elf-contained,=C2=A0but usually comes at a cost in=C2=A0code readability.=
=C2=A0 Tabbing is central enough to the design of FB that it would be invas=
ive to try to take it out at compilation -- of course if someone was motiva=
ted, it&#39;s possible to go do on a local tree to test the final binary si=
ze and compare performance.=C2=A0 You would end up with a slightly smaller =
binary, but the amount of work involved would probably not pay off (and get=
ting it upstreamed is a separate question).</div><div><br></div><div>Matt</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Wed, Apr 20, 2022 at 6:25 AM Maciej M. &lt;<a href=3D"mailto:aznlir8=
[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"auto">Just curious, are the an=
y other things we can not compile into fluxbox besides what is shown after =
&quot;./configure --help&quot;?<div dir=3D"auto"><br></div><div dir=3D"auto=
">For me personally this flexibility is strong attribute of Fluxbox as I do=
 not compile in parts I do not need.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Would love not to compile in window tabbing but as far as I kn=
ow it is not possible. Or maybe I am wrong and there is a way? Anyone?</div=
></div>
_______________________________________________<br>
Fluxbox-users mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Fl=
[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/fluxbox-users" rel=
=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listi=
nfo/fluxbox-users</a><br>
</blockquote></div>

--000000000000114f2905ddf62939--


--===============5739526601990121669==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============5739526601990121669==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Fluxbox-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fluxbox-users

--===============5739526601990121669==--