View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001631 | unreal | installing | public | 2004-03-08 02:32 | 2013-05-07 02:20 |
| Reporter | fez | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | x86 | OS | Linux | OS Version | 2.4.x |
| Product Version | 3.2-RC2 | ||||
| Fixed in Version | 3.4-alpha1 | ||||
| Summary | 0001631: call me crazy, but.... (src/modules/Makefile.in) | ||||
| Description | alright 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 | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Maybe, you should buy a new PC. P166? Looks like, your PC is 9 years old :P |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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 |
|
|
But it isn't the same code. It is slightly different. |
|
|
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 ;) . |
|
|
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. |
|
|
Yeah I agree, spending 20-30 hours coding/testing doesn't seem worth it to save a few hundred KB of disk space. |
|
|
[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 |
|
|
Can we just use automake? :-D |
|
|
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. |
|
|
3.4 compiles only a set of individual modules, so I am closing this. |
| 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 |
|
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 |
|
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 |
|
Note Added: 0006598 | |
| 2005-02-03 19:40 | syzop | Note Added: 0009010 | |
| 2007-04-27 05:48 |
|
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 |
|
Note Added: 0017513 | |
| 2013-05-07 02:20 |
|
Status | acknowledged => resolved |
| 2013-05-07 02:20 |
|
Fixed in Version | => 3.4-alpha1 |
| 2013-05-07 02:20 |
|
Resolution | open => fixed |
| 2013-05-07 02:20 |
|
Assigned To | => nenolod |
