[Gambas-user] [Gambas Bug Tracker] Bug #1006: Debian packaging gone wrong
http://gambaswiki.org/bugtracker/edit?object=BUG.1006&from=L21haW4- C THAL added an attachment: project-anylib-1.0.110.tar.gz -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] [Gambas Bug Tracker] Bug #1006: Debian packaging gone wrong
http://gambaswiki.org/bugtracker/edit?object=BUG.1006&from=L21haW4- Comment #2 by C THAL: project-anylib-1.0.110.tar.gz is the project itself -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] [Gambas Bug Tracker] Bug #1006: Debian packaging gone wrong
http://gambaswiki.org/bugtracker/edit?object=BUG.1006&from=L21haW4- Comment #1 by C THAL: In deganius-anylib-1.0.110.tar.gz you can see the broken debian/control file with wrong entries like ", (>= 0.90.0), (<< 1.0.90)" -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] [Gambas Bug Tracker] Bug #1006: Debian packaging gone wrong
http://gambaswiki.org/bugtracker/edit?object=BUG.1006&from=L21haW4- C THAL added an attachment: deganius-anylib-1.0.110.tar.gz -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] [Gambas Bug Tracker] Bug #1006: Debian packaging gone wrong
http://gambaswiki.org/bugtracker/edit?object=BUG.1006&from=L21haW4- C THAL reported a new bug. Summary --- Debian packaging gone wrong Type : Bug Priority : Medium Gambas version : 3.9.90 (TRUNK) Product : Development Environment Description --- The created debian/control file is broken. Attached is a library of us, the code is deleted, but with code the effect is the same. If one tries to create a Debian package, packaging breaks with this message: == ERSTELLE PAKET FÜR DEBIAN. Erstelle Build-Verzeichnis. Quelldateien werden ins Debian-Format überführt. Erstelle Paket... cd '/home/christof/programming/deganius-apt-pakete/prebuilt-pakete/deganius/deganius-anylib-1.0.110' dpkg-buildpackage -d -rfakeroot -uc -us dpkg-buildpackage: Quellpaket deganius-anylib dpkg-buildpackage: Quellversion 1.0.110-1 dpkg-buildpackage: Quelldistribution unstable dpkg-buildpackage: Quellen geändert durch christof dpkg-buildpackage: Host-Architektur amd64 dpkg-source --before-build deganius-anylib-1.0.110 Die Paketerstellung ist fehlgeschlagen. Package.MakeDebPackage.1080: 'dpkg-buildpackage' ist fehlgeschlagen. == -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] gbc3 in makefile in debuild
Hello Benoît, Am 18.09.2016 um 22:54 schrieb Benoît Minisini: > Le 18/09/2016 à 16:16, Christof Thalhofer a écrit : >> Hi, >> >> for the sake of comfort and speed I compile my gambas projects and libs >> via a makefile and Debian debuild. >> >> So I can do a "debuild binary" in a script and get a project.deb >> >> Since Gambas 3.9 my build breaks, when inside debuild. Here are the >> relevant output lines: >> > > [...] > > Since Gambas 3.9, libraries executables must be copied to > "$DATADIR/gambas3/lib/$VENDOR", $DATADIR being by default > "~/.local/share", and $VENDOR being the vendor name of the library. > > The name of the copy must be the name of the library, followed by ":", > the major version, a dot, the minor version, and ".gambas". > > For example, if your library project is "deg-telefon", the vendor is > "deg", the version is "1.2", and the executable is "deg-telefon.gambas", > you have to copy the executable at > "~/.local/share/gambas3/lib/deg/deg-telefon:1.2.gambas". Thank you! The libs are with correct name in ~/.local/share/gambas3/lib/deganius/... (Vendor name is "deganius") Gambas placed them there when I hammered "Ctrl-X" in the IDE during development. My Makefile defines a couple of Gambas programs and libraries. They are built with gbc3 and gba3. One library depends on the existence of some others. Make builds all correct. The strange thing now is: # debuild binary (which uses the Makefile) fails. At compile time the compiler does not see the existing libraries in ~/.local/share/gambas3/lib/deganius But # dpkg-buildpackage -b (which also uses the Makefile) works ... Ok, the problem is now gone by usage of dpkg-buildpackage, but I'd like to understand what is now different, that since Gambas 3.9.1 debuild is broken ... Alles Gute Christof Thalhofer -- Dies ist keine Signatur signature.asc Description: OpenPGP digital signature -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] gbc3 in makefile in debuild
Le 18/09/2016 à 16:16, Christof Thalhofer a écrit : > Hi, > > for the sake of comfort and speed I compile my gambas projects and libs > via a makefile and Debian debuild. > > So I can do a "debuild binary" in a script and get a project.deb > > Since Gambas 3.9 my build breaks, when inside debuild. Here are the > relevant output lines: > > [...] Since Gambas 3.9, libraries executables must be copied to "$DATADIR/gambas3/lib/$VENDOR", $DATADIR being by default "~/.local/share", and $VENDOR being the vendor name of the library. The name of the copy must be the name of the library, followed by ":", the major version, a dot, the minor version, and ".gambas". For example, if your library project is "deg-telefon", the vendor is "deg", the version is "1.2", and the executable is "deg-telefon.gambas", you have to copy the executable at "~/.local/share/gambas3/lib/deg/deg-telefon:1.2.gambas". Regards, -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] IDE extensions?
I have no opinion for or against. But what would the extensions do? I think the IDE pretty much have all the possible useful things..? I guess something special without general usage. I would be interested in hearing some ideas. Jussi On Sun, Sep 18, 2016 at 12:09 AM, Benoît Minisini < gam...@users.sourceforge.net> wrote: > Hi, > > Would people be interested in some sort of IDE extensions? > > The idea is making a dedicated tag in the software farm for IDE extensions. > > Then, once installed, the extension program is automatically detected by > the IDE. > > Then a menu entry will be added in the IDE. > > When the user clicks on that menu entry, the extension program is run. > It will receive the project path in its argument, and eventually other > informations: the current edited file for example, or whatever else is > needed. > > This is the principle. > > If anymone is interested in something like that, please tell. > > Regards, > > -- > Benoît Minisini > > > -- > ___ > Gambas-user mailing list > Gambas-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user > -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] gbc3 in makefile in debuild
Hi, for the sake of comfort and speed I compile my gambas projects and libs via a makefile and Debian debuild. So I can do a "debuild binary" in a script and get a project.deb Since Gambas 3.9 my build breaks, when inside debuild. Here are the relevant output lines: ---8<-- > Compile Gambas Libraries: > gbc3 -a ./libs/deg-telefon; gbc3 -a ./libs/deg-tabstrip; gbc3 -a > ./libs/deg-models-degdaten; gbc3 -a ./libs/deg-lager; gbc3 -a > ./libs/deg-report; gbc3 -a ./libs/deg-statistik; gbc3 -a ./libs/deg-betrieb; > OK > OK > OK > OK > OK > OK > gbc: warning: cannot find library: deganius/deg-models-degdaten:0.0 > gbc: warning: cannot find library: deganius/deg-report:1.0 > gbc: warning: cannot find library: deganius/deg-statistik:0.0 > gbc: warning: cannot find library: deganius/deg-telefon:0.0 > gbc: warning: cannot find library: deganius/deg-tabstrip:0.0 ---8<-- One can see the last lib does not compile (gbc3 -a ./libs/deg-betrieb fails). It relies on the existence of the other libs compiled before. But if I do "make" instead of "debuild binary" there is no problem: ---8<-- > Compile Gambas Libraries: > gbc3 -a ./libs/deg-telefon; gbc3 -a ./libs/deg-tabstrip; gbc3 -a > ./libs/deg-models-degdaten; gbc3 -a ./libs/deg-lager; gbc3 -a > ./libs/deg-report; gbc3 -a ./libs/deg-statistik; gbc3 -a ./libs/deg-betrieb; > OK > OK > OK > OK > OK > OK > OK ---8<-- It seems that inside debuild gbc3 does not find the path to the existing libs in ~/.local/share/gambas3/lib/deganius/ How can I tell gbc3 where to find the libraries? Any hints? Alles Gute Christof Thalhofer -- Dies ist keine Signatur signature.asc Description: OpenPGP digital signature -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Christmas gift
Am 18.09.2016 um 15:12 schrieb Tobias Boege: > I second this. I may have already mentioned this but soon after the local > library search path was implemented, one of my projects was prospering. > I have taken a habit of calling the module which maintains an application- > or library-specific directory "Config", for the lack of a better universal > word. In my case, I needed both a directory for the application and for > the library, and ended up with two Config modules, the library one of which > was exported. The result was chaos. I did not even think about the name > collision until lots of debugging time passed. If you are able to control the naming inside your own projects, you are in a relatively comfortable position, but if you want to use foreign libs and keep them up to date you are lost in case of conflicts. Alles Gute Christof Thalhofer -- Dies ist keine Signatur signature.asc Description: OpenPGP digital signature -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] IDE extensions?
Le 18/09/2016 à 10:16, Adrien Prokopowicz a écrit : > Le Sat, 17 Sep 2016 23:09:02 +0200, Benoît Minisini > a écrit: > >> Hi, >> >> Would people be interested in some sort of IDE extensions? >> >> The idea is making a dedicated tag in the software farm for IDE >> extensions. >> >> Then, once installed, the extension program is automatically detected by >> the IDE. >> >> Then a menu entry will be added in the IDE. >> >> When the user clicks on that menu entry, the extension program is run. >> It will receive the project path in its argument, and eventually other >> informations: the current edited file for example, or whatever else is >> needed. >> >> This is the principle. >> >> If anymone is interested in something like that, please tell. >> >> Regards, >> > > I like the idea a lot, so i'll add my two cents to the discussion. :-) > > First, I like the idea of using the Software Farm for extensions/plugins. > However, I think it would be nice to have some kind of shortcut > (like Options > IDE Extensions …), because going to the Software Farm > itself isn't very intuitive when you are looking for plugins to install. > > The thing that feels a bit wierd to me, is the implementation itself. > While it is the simplest, having only a menu entry and an executable > being run is very restrictive. > The extension program would have no access to the IDE's state > whatsoever, and would have little to no information about the open project. > > With this design, the only things that I can see being implemented are > programs being run in the current project directory, and running a single > background task, or opening a big pop-up window, because the extension > would need to be completely external. > Therefore, I think the extension should have access to some of the IDE's > classes (the exported ones). > > However, I've noticed that there are quite a bit of Gambas projects > out there, that could be/are using some sort of plugins like this, not > only the IDE. > > Currently, in order to to something like this, you have to mess with > Component.Load(), have the plugin to export some classes, and have the > main application to use some dynamic introspection to fetch some > specific method, and run it. All of this already looks like some > stange voodoo magic. > > Moreover, you cannot directly access the exported Classes from the > plugin's project, because the compiler doesn't know them. > You would have to access them at runtime only, using dynamic introspection, > which is just terrible at this point. > > My point is: I would really like to have a nice, standard way for adding > plugins to Gambas applications, maybe through a component or something. > It would therefore not only be ridiculously easy to add simple plugins > to the IDE (while still allowing to make it evolve and add more features > later), but also for any Gambas application that wants it. :-) > > I've been thinking about something like this for quite some time actually, > and your message raised interest about this to me again. > > Here are the ideas that I came up with, please tell me what you think! :-) > (This is purely in my head, there are probably some things that I missed. > I am just pasting all the ideas I have, I apologize for the long post.) > > In order to easily implement plugins like I described above, two things > are necessary: > - The ability for the application to load plugins from archive files, and >then run a specific method (most likely Main() ). > - The ability for the plugin to access the application's exported classes, >which would basically form an API to let the plugin do anything it wants >(like adding menu entries, extra docks/windows, registering to events...) > > For the first one, I think a simple static method like Plugin.Load(file) > should suffice. It could maybe return a Plugin object with some metadata > about the plugin file (version, authors, …), but that's just extra. > It might be tricky to access the Main() method of the plugin without it > being exported (I don't think it's possible from pure Gambas code), but > the interpeter itself should be able to do this without any problem. > > The second part may be tricky, as both the compiler and the IDE need > information they currently don't have. > > To me, the ideal workflow for a plugin maker would be the following: > - Creating a plugin project, > - Selecting the application I want to create the plugin for, > - All the exported classes from the application are loaded by the >IDE (for autocompletion/documentation), and by the compiler >(for … compiling, I guess). > - (Maybe) Hitting the run button will run the app with the plugin >loaded, allowing for quick testing iterations. > > I'm not sure about the last part, as it would not be possible with > manual plugin loading like a Plugin.Load() method, so another solution > should be found there (if any). > > In order for the rest to work, the compiler and the IDE would need to read > exter
Re: [Gambas-user] Christmas gift
On Sun, 18 Sep 2016, Christof Thalhofer wrote: > If this is a wishlist, I would wish > > Namespaces > > This really could lift Gambas development to a new level because it > would be easy to share libraries without worrying about any name > collissions. > I second this. I may have already mentioned this but soon after the local library search path was implemented, one of my projects was prospering. I have taken a habit of calling the module which maintains an application- or library-specific directory "Config", for the lack of a better universal word. In my case, I needed both a directory for the application and for the library, and ended up with two Config modules, the library one of which was exported. The result was chaos. I did not even think about the name collision until lots of debugging time passed. Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] [Gambas Bug Tracker] Bug #1005: Gambas 3.9 crashes when creating a Debian package from library
http://gambaswiki.org/bugtracker/edit?object=BUG.1005&from=L21haW4- Comment #3 by C THAL: Fetched Daily from Launchpad. No crash :-) C THAL changed the state of the bug to: Invalid. -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] [Gambas Bug Tracker] Bug #1005: Gambas 3.9 crashes when creating a Debian package from library
http://gambaswiki.org/bugtracker/edit?object=BUG.1005&from=L21haW4- Comment #2 by Benoît MINISINI: No crash at all there. Can you try the latest version (3.9.1)? -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Christmas gift
If this is a wishlist, I would wish Namespaces This really could lift Gambas development to a new level because it would be easy to share libraries without worrying about any name collissions. Alles Gute Christof Thalhofer -- Dies ist keine Signatur signature.asc Description: OpenPGP digital signature -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] [Gambas Bug Tracker] Bug #1005: Gambas 3.9 crashes when creating a Debian package from library
http://gambaswiki.org/bugtracker/edit?object=BUG.1005&from=L21haW4- Comment #1 by C THAL: I just see, Gambas also crashes if the project is a normal project, not a lib ... awful ... -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] [Gambas Bug Tracker] Bug #1005: Gambas 3.9 crashes when creating a Debian package from library
http://gambaswiki.org/bugtracker/edit?object=BUG.1005&from=L21haW4- C THAL added an attachment: test2-0.0.1.tar.gz -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] [Gambas Bug Tracker] Bug #1005: Gambas 3.9 crashes when creating a Debian package from library
http://gambaswiki.org/bugtracker/edit?object=BUG.1005&from=L21haW4- C THAL reported a new bug. Summary --- Gambas 3.9 crashes when creating a Debian package from library Type : Bug Priority : High Gambas version : 3.9 Product : Development Environment Description --- I attach a small test project with quite nothing in it. It's a library. If one creates an installation package (a Debian *.deb) from it, Gambas3 crashes on my system with segmentation fault. [System] Gambas=3.9 OperatingSystem=Linux Kernel=4.4.0-36-generic Architecture=x86_64 Distribution=Ubuntu 16.04.1 LTS Desktop=XFCE Theme=Gtk Language=de_DE.UTF-8 Memory=7683M [Libraries] Cairo=libcairo.so.2.11400.6 Curl=libcurl.so.4.4.0 DBus=libdbus-1.so.3.14.6 GStreamer=libgstreamer-0.10.so.0.30.0 GStreamer=libgstreamer-1.0.so.0.802.0 GTK+2=libgtk-x11-2.0.so.0.2400.30 GTK+3=libgtk-3.so.0.1800.9 OpenGL=libGL.so.1.2.0 Poppler=libpoppler.so.44.0.0 Poppler=libpoppler.so.58.0.0 QT4=libQtCore.so.4.8.7 QT5=libQt5Core.so.5.5.1 SDL=libSDL-1.2.so.0.11.4 SQLite=libsqlite3.so.0.8.6 [Environment] CLUTTER_IM_MODULE=xim DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-wdpYkW8DbR DEFAULTS_PATH=/usr/share/gconf/xfce.default.path DESKTOP_SESSION=xfce DISPLAY=:0.0 GB_GUI=gb.qt4 GDMSESSION=xfce GLADE_CATALOG_PATH=: GLADE_MODULE_PATH=: GLADE_PIXMAP_PATH=: GNOME_KEYRING_CONTROL= GNOME_KEYRING_PID= GTK_IM_MODULE=xim GTK_MODULES=canberra-gtk-module:canberra-gtk-module:gail:atk-bridge HOME= IM_CONFIG_PHASE=1 INSTANCE= JOB=dbus LANG=de_DE.UTF-8 LIBVIRT_DEFAULT_URI=qemu:///system LOGNAME= MANDATORY_PATH=/usr/share/gconf/xfce.mandatory.path PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin PWD= QT4_IM_MODULE=xim QT_ACCESSIBILITY=1 QT_IM_MODULE= QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 QT_QPA_PLATFORMTHEME=appmenu-qt5 SESSION=xfce SESSIONTYPE= SESSION_MANAGER=local/:@/tmp/.ICE-unix/5766,unix/:/tmp/.ICE-unix/5766 SHELL=/usr/bin/zsh SHLVL=0 SSH_AGENT_PID=5774 SSH_AUTH_SOCK=/tmp/ssh-ozllUgOsHPoQ/agent.5773 TZ=:/etc/localtime UPSTART_EVENTS=started xsession UPSTART_INSTANCE= UPSTART_JOB=startxfce4 UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/5487 USER= USERNAME= WINDOWPATH=7 XAUTHORITY=/run/user/1000/gdm/Xauthority XDG_CONFIG_DIRS=/etc/xdg/xdg-xfce:/usr/share/upstart/xdg:/etc/xdg:/etc/xdg XDG_CURRENT_DESKTOP=XFCE XDG_DATA_DIRS=/usr/share/xfce:/usr/share/xfce4:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop:/usr/share XDG_MENU_PREFIX=xfce- XDG_RUNTIME_DIR=/run/user/1000 XDG_SEAT=seat0 XDG_SESSION_COOKIE=87078baa605ff4b5a30b8302001b-1473952135.769785-40551053 XDG_SESSION_DESKTOP=xfce XDG_SESSION_ID=1 XDG_SESSION_TYPE=x11 XDG_VTNR=7 XMODIFIERS=@im=none -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] IDE extensions?
Le Sat, 17 Sep 2016 23:09:02 +0200, Benoît Minisini a écrit: > Hi, > > Would people be interested in some sort of IDE extensions? > > The idea is making a dedicated tag in the software farm for IDE > extensions. > > Then, once installed, the extension program is automatically detected by > the IDE. > > Then a menu entry will be added in the IDE. > > When the user clicks on that menu entry, the extension program is run. > It will receive the project path in its argument, and eventually other > informations: the current edited file for example, or whatever else is > needed. > > This is the principle. > > If anymone is interested in something like that, please tell. > > Regards, > I like the idea a lot, so i'll add my two cents to the discussion. :-) First, I like the idea of using the Software Farm for extensions/plugins. However, I think it would be nice to have some kind of shortcut (like Options > IDE Extensions …), because going to the Software Farm itself isn't very intuitive when you are looking for plugins to install. The thing that feels a bit wierd to me, is the implementation itself. While it is the simplest, having only a menu entry and an executable being run is very restrictive. The extension program would have no access to the IDE's state whatsoever, and would have little to no information about the open project. With this design, the only things that I can see being implemented are programs being run in the current project directory, and running a single background task, or opening a big pop-up window, because the extension would need to be completely external. Therefore, I think the extension should have access to some of the IDE's classes (the exported ones). However, I've noticed that there are quite a bit of Gambas projects out there, that could be/are using some sort of plugins like this, not only the IDE. Currently, in order to to something like this, you have to mess with Component.Load(), have the plugin to export some classes, and have the main application to use some dynamic introspection to fetch some specific method, and run it. All of this already looks like some stange voodoo magic. Moreover, you cannot directly access the exported Classes from the plugin's project, because the compiler doesn't know them. You would have to access them at runtime only, using dynamic introspection, which is just terrible at this point. My point is: I would really like to have a nice, standard way for adding plugins to Gambas applications, maybe through a component or something. It would therefore not only be ridiculously easy to add simple plugins to the IDE (while still allowing to make it evolve and add more features later), but also for any Gambas application that wants it. :-) I've been thinking about something like this for quite some time actually, and your message raised interest about this to me again. Here are the ideas that I came up with, please tell me what you think! :-) (This is purely in my head, there are probably some things that I missed. I am just pasting all the ideas I have, I apologize for the long post.) In order to easily implement plugins like I described above, two things are necessary: - The ability for the application to load plugins from archive files, and then run a specific method (most likely Main() ). - The ability for the plugin to access the application's exported classes, which would basically form an API to let the plugin do anything it wants (like adding menu entries, extra docks/windows, registering to events...) For the first one, I think a simple static method like Plugin.Load(file) should suffice. It could maybe return a Plugin object with some metadata about the plugin file (version, authors, …), but that's just extra. It might be tricky to access the Main() method of the plugin without it being exported (I don't think it's possible from pure Gambas code), but the interpeter itself should be able to do this without any problem. The second part may be tricky, as both the compiler and the IDE need information they currently don't have. To me, the ideal workflow for a plugin maker would be the following: - Creating a plugin project, - Selecting the application I want to create the plugin for, - All the exported classes from the application are loaded by the IDE (for autocompletion/documentation), and by the compiler (for … compiling, I guess). - (Maybe) Hitting the run button will run the app with the plugin loaded, allowing for quick testing iterations. I'm not sure about the last part, as it would not be possible with manual plugin loading like a Plugin.Load() method, so another solution should be found there (if any). In order for the rest to work, the compiler and the IDE would need to read external info files from a specific target. Info files can be generated easily from source project, and I think you can extract them from executable archives (not sure about this one) ? I think the nicest way to do this is to cre
