View Issue Details

IDProjectCategoryView StatusLast Update
0001631unrealinstallingpublic2013-05-07 02:20
ReporterfezAssigned Tonenolod 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Platformx86OSLinuxOS Version2.4.x
Product Version3.2-RC2 
Target VersionFixed in Version3.4-alpha1 
Summary0001631: call me crazy, but.... (src/modules/Makefile.in)
Descriptionalright this is a little suggestion... kind of a philosophical one really. I'm anxious to hear your replies.

When I download a new version of Unreal, the first thing I do is modify src/modules/Makefile.in, so that....

instead of compiling every .c file into this giant l_commands wrapper at once (which takes like an hour on my p/166), and then compiling each and every .c into it's own .so,
I instead remove -DDYNAMIC_LINKING, and compile each of the .c files into a .o object, then just link them together to form commands.so

as a result, compilation time is improved CONSIDERABLY, and, on systems which have the nasty sig11 problem (like mine) or have some other issue, a break in compiling in the middle of commands.so doesn't mean i have to start the whole thing over from scratch!.....

On the downside... a power-user wouldn't be able to select the very specific commands they wanted to load by loading the individual .so's instead of commands.so, but...
a power-user who wanted to do that could probably figure out to do a make custommodule on them, and really I don't think anyone cares whether every single .c has a .so....

so to summarize, I suggest compiling to .o instead of .so to save time and accelerate potential changes to individual changes to modules... (e.g., now if i make a little modification to, say, m_whois.c, i don't have to recompile the WHOLE commands.so... just that one object, then re-link).

Even if this idea is turned down I still think it might be nice to have an alternate Makefile... or perhaps make this a ./Config option or something......

Thoughts?


 -- fez
TagsNo tags attached.
3rd party modules

Activities

Rocko

2004-03-08 08:20

reporter   ~0005349

Maybe, you should buy a new PC. P166? Looks like, your PC is 9 years old :P

codemastr

2004-03-08 12:34

reporter   ~0005362

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.

aquanight

2004-06-04 01:26

reporter   ~0006571

Last edited: 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

syzop

2004-06-04 14:33

administrator   ~0006590

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.

aquanight

2004-06-04 14:40

reporter   ~0006592

Last edited: 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

codemastr

2004-06-04 15:06

reporter   ~0006594

But it isn't the same code. It is slightly different.

aquanight

2004-06-04 15:12

reporter   ~0006595

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 ;) .

syzop

2004-06-04 15:31

administrator   ~0006597

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.

codemastr

2004-06-04 15:49

reporter   ~0006598

Yeah I agree, spending 20-30 hours coding/testing doesn't seem worth it to save a few hundred KB of disk space.

syzop

2005-02-03 19:40

administrator   ~0009010

[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

ohnobinki

2010-05-06 23:43

reporter   ~0016083

Can we just use automake? :-D

syzop

2010-07-02 10:28

administrator   ~0016137

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.

nenolod

2013-05-07 02:20

reporter   ~0017513

3.4 compiles only a set of individual modules, so I am closing this.

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
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 added child of 0003915
2012-10-06 12:23 syzop Relationship deleted child of 0003915
2013-05-07 02:20 nenolod Note Added: 0017513
2013-05-07 02:20 nenolod Status acknowledged => resolved
2013-05-07 02:20 nenolod Fixed in Version => 3.4-alpha1
2013-05-07 02:20 nenolod Resolution open => fixed
2013-05-07 02:20 nenolod Assigned To => nenolod