Author Topic: code::blocks::embedded  (Read 18832 times)

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #15 on: September 21, 2010, 11:01:38 pm »
simply get the GDB source package and you develop until you get something usable. So if want to get output from command e.g. "info locals" you can split it into several libgdbXXX.dll calls create you own API and use it for your plugin. Solutions which parsing some output from other processes does not like for me and much more in case of debugger.

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11491
    • Travis build status
Re: code::blocks::embedded
« Reply #16 on: September 21, 2010, 11:07:33 pm »
So this is your independent lib based on the sources of gdb?

I don't like this parsing, too, but it is the only long term solution for using gdb.
The llvm's debugger will be lib based which is good :)
« Last Edit: September 21, 2010, 11:10:10 pm by oBFusCATed »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #17 on: September 21, 2010, 11:14:24 pm »
libgdbXXX.dll + libAPI.dll + C::B related work = debugger plugin
also usable as the libgdbXXX.dll + stub  = GDB.EXE

Upon target device selection for a project can in future use different variants of libgdbXXX.dll as ARM, MIPS, SUPERH etc.

I agree that in open world is quite hard to maintain such kind of code

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #18 on: September 21, 2010, 11:49:26 pm »
I just want to ask how far is the time when your C::B turns into commercial edit ?

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11491
    • Travis build status
Re: code::blocks::embedded
« Reply #19 on: September 21, 2010, 11:58:16 pm »
What exactly do you ask?

1. If some company will buy C::B and thus C::B becomes a proprietary software?
2. If C::B will catch the commertial IDEs (like VStudio)?

1. never
2. it depends on the user's contrubution I think :), btw in some areas it is ages in front of VStudio, in some it is quite behind...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #20 on: September 22, 2010, 12:05:18 am »
1. sounds line SOCIALISM past 20 years in eastern EUROPE where nobody owned nothing
2. incomparable motivation  :(
3. what are then the DONATIONS on your C::B page ?

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6434
    • My Best Post
Re: code::blocks::embedded
« Reply #21 on: September 22, 2010, 04:19:49 am »
I just want to ask how far is the time when your C::B turns into commercial edit ?

I suggest you read up an the GPL; turning an GPL program into an commercial program is not easy/legal/possible by anyone but the copyright owner.
And, with the copyright being owned by multiple people is likely impossible.
http://en.wikipedia.org/wiki/Gpl

And, since it is an open source license; there would be a fork by any developer/user who wanted to fork it.

Tim S.
« Last Edit: September 22, 2010, 04:24:42 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #22 on: September 22, 2010, 08:00:03 am »
On what conditions can be plugins kept closed source ?

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11491
    • Travis build status
Re: code::blocks::embedded
« Reply #23 on: September 22, 2010, 11:51:32 am »
etg: It was communism not socialism :)

I think the license for the SDK is GPL 3, so if you distribute the plugin you should provide
the source to the person your are distributing the plugin (he/she can pay you for plugin, it is not forbidden by the license).

Probably this could shed some light: http://www.gnu.org/licenses/gpl-faq.html
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2119
Re: code::blocks::embedded
« Reply #24 on: September 22, 2010, 01:01:56 pm »
etg: It was communism not socialism :)

I think the license for the SDK is GPL 3, so if you distribute the plugin you should provide
the source to the person your are distributing the plugin (he/she can pay you for plugin, it is not forbidden by the license).

Probably this could shed some light: http://www.gnu.org/licenses/gpl-faq.html

The license on the CB SDK is not GPL 3. Its LGPL 3, which allows commercial ownership and distribution.

Code: [Select]
/*
 * This file is part of the Code::Blocks IDE and licensed under the GNU Lesser General Public License, version 3
 * http://www.gnu.org/licenses/lgpl-3.0.html

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6434
    • My Best Post
Re: code::blocks::embedded
« Reply #25 on: September 22, 2010, 03:56:40 pm »
Per Pecan, Since Code::Blocks uses the LGPL 3 making an close source plugin for Code::Blocks allowed.
Note: The close source plugin (Binary) for Code::Blocks must NOT contain static linked code compiled from GPL or LGPL source code(Without permission from Copyright Owner); it can link to the Code::Blocks SDK (Since it is Licensed under LGPL).

I am not a lawyer; and I am not an expert on Code::Blocks or the GPL/LGPL. But, I have read discussions on both.

« Last Edit: September 22, 2010, 05:05:24 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline etg

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: code::blocks::embedded
« Reply #26 on: September 22, 2010, 05:01:39 pm »
Who is aware of any commercial derivatite of C::B or plugin for C::B ?
I think would be better not to allow fully closed source but everybody should provide some useful part not whole (depends) from code for future integration in C::B in case commercial onwership of such release.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6434
    • My Best Post
Re: code::blocks::embedded
« Reply #27 on: September 22, 2010, 05:13:06 pm »
There was about two years back an Site that was using Code::Blocks as the IDE for their embedded hardware; not sure if it counts as an commercial product. Edit: I think they are selling it; do not really read the website enough to confirm it.
I think they was including Code::Blocks for free. They might have had some custom plugins for C::B.

I can not remember their name right now.
Found a possible match
http://imagecraft.wordpress.com/2009/10/20/next-gen-ide-codeblocks-pre-alpha/

Tim S
« Last Edit: September 22, 2010, 07:18:09 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline pfong

  • Multiple posting newcomer
  • *
  • Posts: 14
Re: code::blocks::embedded
« Reply #28 on: September 22, 2010, 06:25:21 pm »
Does code::blocks use the GDB mi interface in the debugger branch?  This would probably be better than the current stdin/stdout redirection method since it let's you interact with GDB while the debugee is running and you can stop individual threads.

Also, I think it is better to use a separate GDB rather than a custom library.  This way you can build/get GDB for whatever target you are using rather than trying to adapt and recompile a custom library.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6434
    • My Best Post
Re: code::blocks::embedded
« Reply #29 on: September 22, 2010, 07:20:17 pm »
Also, I think it is better to use a separate GDB rather than a custom library.  This way you can build/get GDB for whatever target you are using rather than trying to adapt and recompile a custom library.

I do NOT use debugger; but, I believe Code::Blocks has always used a separate GDB.

Edit: @pfong, you do realize this this thread is about an outside developer creating a project using parts of Code::Blocks.

Tim S.
« Last Edit: September 22, 2010, 07:28:45 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org