Re: What can we not compile into fluxbox?
"M. M." <[email protected]> Sat, 7 May 2022 12:17:51 +0100
| Newsgroups | gmane.comp.window-managers.fluxbox.user |
|---|---|
| Message-ID | <CANm-CJGUiAfbDqs0XcKuo15dCJLy2oT1h=ik84v5BcM=e4sgqw@mail.gmail.com> |
--===============0987864584740693321== Content-Type: multipart/alternative; boundary="000000000000dc08f105de6a2042" --000000000000dc08f105de6a2042 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Woah! That was much more detailed answer than I would have ever expected. Thank you for your answer, you convinced me that it is not worth the effort. Also I lack the knowledge to do so. niedz., 1 maj 2022 o 17:56 Matt Banack <[email protected]> napisa=C5=82(a): > 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, #ifde= f > 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 eve= r > 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 compa= re > 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 d= o >> 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 >> > --000000000000dc08f105de6a2042 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Woah! That was much more detailed answer than I would= have ever expected. Thank you for your answer, you convinced me that it is= not worth the effort. Also I lack the knowledge to do so. </div></div><br>= <div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">niedz., 1 = maj 2022 o 17:56=C2=A0Matt Banack <<a href=3D"mailto:[email protected]">= [email protected]</a>> napisa=C5=82(a):<br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex"><div dir=3D"ltr">Hi Maciej,<div><br></div><div>W= ith the caveat that I'm a passionate user and haven't contributed a= nything to the codebase (yet).=C2=A0 The short answer is no, unless you'= ;re willing to dive into the source and change things.</div><div><br></div>= <div>>=C2=A0<span style=3D"color:rgb(0,0,0)">Just curious, are the any o= ther things we can not compile into fluxbox besides what is shown after &qu= ot;./configure --help"?</span></div><div>If you're interested in t= he internals, you can look at the autoconf file <a href=3D"http://configure= .ac" target=3D"_blank">configure.ac</a> and see how those configure options= get mapped to #defines.=C2=A0 Then you can look through the code for thing= s like #ifdef XINERAMA, #ifdef USE_TOOLBAR.=C2=A0 If you *really* want to s= lim down your binary as much as possible, you could look at the config.h de= fines starting with HAVE_ and evaluate them individually... if you override= the detection for which things you have available, some of those will comp= ile out code, but some of them will just take alternate paths.=C2=A0 You wi= ll likely be sacrificing features and/or performance by doing this, but it&= #39;s up to you to evaluate them individually.=C2=A0 There is an implicit a= ssumption that no one would ever want to turn those off, but YMMV.</div><di= v><br></div><div>As far as window managers go, fluxbox is already on the ex= tremely lean side.=C2=A0 I think you will find that the benefit of not comp= iling something like tab support (if you're not using tabs) doesn't= get you any real performance win.</div><div><br></div><div>#ifdef can work= well for some things that are relatively self-contained,=C2=A0but usually = comes at a cost in=C2=A0code readability.=C2=A0 Tabbing is central enough t= o the design of FB that it would be invasive to try to take it out at compi= lation -- 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.=C2=A0 = You would end up with a slightly smaller binary, but the amount of work inv= olved would probably not pay off (and getting it upstreamed is a separate q= uestion).</div><div><br></div><div>Matt</div></div><br><div class=3D"gmail_= quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 20, 2022 at 6:25 A= M Maciej M. <<a href=3D"mailto:[email protected]" target=3D"_blank">azn= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex"><div dir=3D"auto">Just curious, are the any other things we = can not compile into fluxbox besides what is shown after "./configure = --help"?<div dir=3D"auto"><br></div><div dir=3D"auto">For me personall= y this flexibility is strong attribute of Fluxbox as I do not compile in pa= rts 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 know it is not possi= ble. 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> </blockquote></div> --000000000000dc08f105de6a2042-- --===============0987864584740693321== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0987864584740693321== 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 --===============0987864584740693321==--