Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

OpenFilesListPlus plugin

<< < (3/5) > >>

earlgrey:

--- Quote from: Abdulqayoom on December 22, 2015, 05:19:02 pm ---how insttal it

--- End quote ---

Which platform ? I would willingly help, the more so as I didn't get many hits on github, although I find my plugin convenient & awsome :)

earlgrey:

--- Quote from: oBFusCATed on September 27, 2015, 05:28:28 pm ---You can check this plugin https://github.com/obfuscated/cb_gdbmi for an example how to implement an autotools based build system for your plugin.

--- End quote ---

I' ve done that, but gcc 4.9.2 define the two macros linux and  unix

--- Code: ---cpp -dM ./empty-file.hxx
#define __DBL_MIN_EXP__ (-1021)
...
#define unix 1
...
#define linux 1
...
#define __ATOMIC_RELEASE 3

--- End code ---

which conflict with 2 static const bool in prep.h :


--- Code: ---@line 222 : const bool linux   = (id == platform_linux);
@line 228 : const bool unix    = (linux | freebsd | netbsd | openbsd | darwin | solaris);

--- End code ---

so you get a "expected unqualified id before numeric constant" error

oBFusCATed:
You need to pass -ansi to the compiler or switch to c++11/14.

MortenMacFly:

--- Quote from: earlgrey on September 27, 2015, 05:14:37 pm ---Installation instructions are on the wiki, but are only complete for Linux at the moment.

--- End quote ---
BTW: You don't provide Windows project files. So many people will miss your plugin effort.

MortenMacFly:

--- Quote from: MortenMacFly on January 01, 2016, 05:00:09 pm ---BTW: You don't provide Windows project files. So many people will miss your plugin effort.

--- End quote ---
OK, I tried to make a Windows project file so I had to look into it.

Unfortunately I have to say although I like the idea I finally gave up. I think in the current stage as the plugin is it won't make it into an official plugin. Here are the various reasons:
- strange file handling with *.cci *.hhi (not conform to C::B standards)
- not following C::B coding guidelines
- using jump marks
- a lot of serious compiler warnings that should be fixed
- many, many #defines for checking "something" the plugin does not need.
- added a lot complexity due to incorporating debug code (in fact it looks to me that w/o debug code the plugin would be 10% of the size)

I am not offending but I would let you now my thoughts. Please keep in mind that we better need to remove complexity from the project, not add. The code must be easy to read, understand and follow. If you want to experiment with features that are not required for the actual plugins functionality you should better use wrapper classes and do whatever you want in there.

Maybe you can create a simple, cleaned-up version in a release branch?

Navigation

[0] Message Index

[#] Next page

[*] Previous page