User forums > Help

wxSmith on LINUX

<< < (2/3) > >>

thomas:
If we enable them by default, there is no point for them being contrib plugins. We could as well move them to the other folder then.

However, there may be people who don't want contrib plugins at all, or only a subset of them.
For example, I regularly compile wxSmith and Help by hand because those are the only contrib plugins I ever use.

Especially since you are someone who experiences quite long loading times, you should actually have had a thought about removing a few things that you never use.

takeshimiya:

--- Quote from: thomas on May 12, 2006, 09:34:48 am ---If we enable them by default, there is no point for them being contrib plugins. We could as well move them to the other folder then.

--- End quote ---
That's not entirely true.


--- Quote from: thomas on May 12, 2006, 09:34:48 am ---However, there may be people who don't want contrib plugins at all, or only a subset of them.

--- End quote ---
--disable-contrib for them.
I bet most people want then compiled. A poll could resolve what should be the default.


--- Quote from: thomas on May 12, 2006, 09:34:48 am ---Especially since you are someone who experiences quite long loading times, you should actually have had a thought about removing a few things that you never use.

--- End quote ---
That commentary is really out of place. Changing the default value for a configure flag doesn't have anything to do with loading times, since you can disable the plugins loading from within C::B.


--- Quote from: thomas on May 12, 2006, 09:34:48 am ---For example, I regularly compile wxSmith and Help by hand because those are the only contrib plugins I ever use.

--- End quote ---
I for one, preffer to compile all plugins, and later at run-time, choose the ones I use most often.


Do you have any other short-term solution for KirkD, MortenMacFly, and other linux users?
I mean, we're already compiling and distributing contrib plugins in Windows for both stable and nightly builds.

Clearing the issue: for a long-term solution, of course the contrib plugins will be probably removed, because when C::B will have a big quantity of plugins made (like Eclipse) it will be the right time, but just now we have a reasonable small quantity of plugins.
Probably in the future even the contrib plugins will have to be sorted out of the codebase repository, moved to their own plugins repositories and mantained independently, downloaded trough the new codepacks :P


Again, I'm only talking about a short/medium-term solution, that is changing the configure default option, without forcing anyone, with the intentions of making it a little bit easier for the linux users.

thomas:

--- Quote ---Do you have any other short-term solution for KirkD, MortenMacFly, and other linux users?
--- End quote ---
Yes, --enable-contrib.

MortenMacFly:

--- Quote from: Takeshi Miya on May 12, 2006, 09:58:18 am ---Again, I'm only talking about a short/medium-term solution, that is changing the configure default option, without forcing anyone, with the intentions of making it a little bit easier for the linux users.

--- End quote ---
I would agree with Thomas here. The reason I didn't know is because I'm not familiar with autotools and stuff on linux. Anyway: A linux user should know the ./configure --help option (me included) which will reveal "--enable-contrib", the default and a lot other options. A developer on linux (again: me included!) really should know that if (s)he tries to compile C::B from the sources (!). Otherwise (s)he should use the pre-compiled packages.
In addition: I (as really not an expert in linux) was able to run make myself - so as long as the Makefiles are being created OK using the default configure it's OK I'd say.
With regards, Morten.

takeshimiya:
Ok, since I know the existence of --enable-contrib, it's not really a problem for me.

Navigation

[0] Message Index

[#] Next page

[*] Previous page