0001631: call me crazy, but.... (src/modules/Makefile.in)

Notes
(0005349) Rocko (reporter) 2004-03-08 08:20	Maybe, you should buy a new PC. P166? Looks like, your PC is 9 years old :P

(0005362) codemastr (reporter) 2004-03-08 12:34	Heh, don't make fun of a P166! Anyway, what I think I'm going to do before 3.2-final is a ./Config question "Do you want to generate commands.so? Or just the individual m_commandname.so?" Or something like that. That way for those who still want both, they can have both, for those who want one, they can have one.

(0006571) aquanight (reporter) 2004-06-04 01:26 edited on: 2004-06-04 01:27	Heh, still open? ;) Anyway, sorry to dig up an oldie, but... Is it possible to have commands.so just turn around and reference the individual .so/dll modules, instead of compiling the .c's into .so/.dll and then into a single blob that is the current commands.so/dll? This would not only maintain compiling the m_* to .so/.dll (and providing the ability to leave some out), but also reduce compile time and disk space usage by not having multiple copies of the same code (one in commands.so/.dll and one in m_.so/.dll). After all, the purpose of shared/dynamic-link libraries is to reduce disk space by having the code exist in one place that all executables share - hence shared* libraries. edit: maybe not the _only_ purpse, but that's a pretty significant one if you ask me... edited on: 2004-06-04 01:27

(0006590) syzop (administrator) 2004-06-04 14:33	Actually in our case that's not the the purpose, nor is it significant.. In fact if you would link in the modules statically it even uses a bit less hd space and less memory (less headerstuff, less extra memory areas, etc) ;). Our modules are not like libraries in the sense that other programs use them, so what you said doesn't make much sense... Then again I think you already realized that ;). The main advantages of modules for us are: - Easy to have 3rd party coders code stuff and plug them in - Possible to upgrade parts WITHOUT rebooting the ircd (could even fix security bugs in cmds without reboot!) - You can rip out commands if you want (with that one you can save mem, although that's rarely the reason.. Instead, think of people hating certain commands like /addline ;p) - You can make certain 'choices' at runtime / without recompiling, like in CVS which requires you to load one of the cloaking modules.

(0006592) aquanight (reporter) 2004-06-04 14:40 edited on: 2004-06-04 14:41	Yeah, but as I said, having two copies of the same code is just a waste of space. By having command.so just reference the individual .so's it could not only reduce space used by duplicate code, but also allow admins to remove commands without having to switch from loadmodule "commands.so" to loadmodule "m_.so", which may not be good because said admin may have other m_ modules that he doesn't want loaded atm (buggy, memleaks, abuse, other reasons) or already has a loadmodule line for. For example, I just rename m_addline.{so\|dll} to m_addline.{so\|dll}.disabled. Commands.{so\|dll} loads during /rehash, and tries to load m_addline.{so\|dll}. Fails, so it just moves on (and not load that command). The only time such a ".{so\|dll} not found" error would be fatal in this case is if it's one of the required commands that Unreal checks for (and says it's RTFM thing). edited on: 2004-06-04 14:41

(0006594) codemastr (reporter) 2004-06-04 15:06	But it isn't the same code. It is slightly different.

(0006595) aquanight (reporter) 2004-06-04 15:12	Different code? You mean the MOD_* stuff? Or something else I'm missing? Even if there are slight differences, my guess is that 99.9% of the code is identical, which is for me usually enough to consider abstracting/modulizing/whateverizing it. Unless there is some significant functional difference in having commands.so just reference the individual modules (besides performance hits). I dunno... Though I can see that symbol references can be a major headache. You most definitely cannot use implicit or delay-load (Win32?) linking if you do this... ;) . Which means more fun dlopen()/LoadLibrary() calls ;) .

(0006597) syzop (administrator) 2004-06-04 15:31	I don't really like the idea.. It's like black magic in the background plus it requires all kind of work/implementation crap (=bugs)... The current way works just fine IMO.

(0006598) codemastr (reporter) 2004-06-04 15:49	Yeah I agree, spending 20-30 hours coding/testing doesn't seem worth it to save a few hundred KB of disk space.

(0009010) syzop (administrator) 2005-02-03 19:40	[quote]Anyway, what I think I'm going to do before 3.2-final is a ./Config question "Do you want to generate commands.so? Or just the individual m_commandname.so?"[/quote] I'm beginning to like this, unfortunately I'm not really into configure/autoconf & friends so I don't think I can do this... but since a lot of code is (being) modulized, the extra compile time (and diskspace I guess) it requires is getting annoying [I'm on a P450 btw :P]. Currently I'm just commenting around in src/modules/Makefile whenever I need to recompile a lot, but that's a great solution, and it would be much nicer if it was automated ;p

(0016083) ohnobinki (developer) 2010-05-06 23:43	Can we just use automake? :-D

(0016137) syzop (administrator) 2010-07-02 10:28	We should still have a question which should decide what to compile 1) Only individual modules 2) Only commands.so, cloak.so 3) Both Should default to both I think, and should receive much testing. I'm setting this to 3.2.10, it's not that important.

Issue History
Date Modified	Username	Field	Change
2004-03-08 02:32	fez	New Issue
2004-03-08 08:20	Rocko	Note Added: 0005349
2004-03-08 12:34	codemastr	Note Added: 0005362
2004-06-04 01:26	aquanight	Note Added: 0006571
2004-06-04 01:27	aquanight	Note Edited: 0006571
2004-06-04 14:33	syzop	Note Added: 0006590
2004-06-04 14:40	aquanight	Note Added: 0006592
2004-06-04 14:41	aquanight	Note Edited: 0006592
2004-06-04 15:06	codemastr	Note Added: 0006594
2004-06-04 15:12	aquanight	Note Added: 0006595
2004-06-04 15:31	syzop	Note Added: 0006597
2004-06-04 15:49	codemastr	Note Added: 0006598
2005-02-03 19:40	syzop	Note Added: 0009010
2007-04-27 05:48	stskeeps	Status	new => feedback
2007-04-27 05:48	stskeeps	Relationship added	child of 0003049
2010-05-06 23:43	ohnobinki	Note Added: 0016083
2010-07-02 10:27	syzop	QA	=> Not touched yet by developer
2010-07-02 10:27	syzop	U4: Need for upstream patch	=> No need for upstream InspIRCd patch
2010-07-02 10:27	syzop	U4: Upstream notification of bug	=> Not decided
2010-07-02 10:27	syzop	U4: Contributor working on this	=> None
2010-07-02 10:27	syzop	Status	feedback => acknowledged
2010-07-02 10:27	syzop	Additional Information Updated
2010-07-02 10:28	syzop	Note Added: 0016137
2010-07-02 10:28	syzop	Additional Information Updated
2010-07-02 10:28	syzop	Relationship deleted	child of 0003049
2010-07-02 10:28	syzop	Relationship added	child of 0003915