Re: gEDA-user: pcb library and hid build modification
On Tue, 26 May 2009, Jason Childs wrote: >On Tue, May 26, 2009 at 8:38 PM, John Griessen wrote: >> To control drawing tools via a plugin in any language >> Igor/Tibor's GPMI interface allows would be fabulous! Think of all the >> extra efforts >> that people would make in all their different favorite scripting languages? >> Just like SWIG, and we already have it. > >Do you have a working link to the GPMI hid? I can't seem to find any that work. > http://repo.hu/projects/pcb-gpmi/ Current state: the infrastructure is ready and some things are already accessible trough the bindings (can pop up custom dialogs, can modify the drawing in memory, add new exporter). Still a lot to do on improving bindings so more of PCB internals are exposed. If you want to write an exporter to xml, you already can write it (there's an example SVG exporter). Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
On Tue, May 26, 2009 at 11:05 PM, DJ Delorie wrote: > >> > %.so : %.c >> > gcc $(INCLUDES) -g -O2 -Wall -shared $< -o $@ >> > >> >> This creates DYN objects for each .c file, the objects created during >> PCB's current build are REL not DYN... The goal was to have PCB and >> the bindings not have duplicate object code... which a shared library >> would solve. > > Er, what? Each C file is compiled once. The core files are compiled > and linked into pcb; the plugin's files are compiled once and linked > into the .so. When PCB loads a plugin, the dynamic linker finishes > the link by resolving the plugin's references with symbols from the > pcb app. The plugins have no core code in them. > Er, no, not talking about plugins, talking about bindings... again, you are looking at it backwards from how I was looking at it (or I was looking at it backwards from how you are looking at it), ergo... >> everyone has to add-on to PCB... > > Right. Ok, but not sure I agree with the philosophy. Jason ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
> > %.so : %.c > > gcc $(INCLUDES) -g -O2 -Wall -shared $< -o $@ > > > > This creates DYN objects for each .c file, the objects created during > PCB's current build are REL not DYN... The goal was to have PCB and > the bindings not have duplicate object code... which a shared library > would solve. Er, what? Each C file is compiled once. The core files are compiled and linked into pcb; the plugin's files are compiled once and linked into the .so. When PCB loads a plugin, the dynamic linker finishes the link by resolving the plugin's references with symbols from the pcb app. The plugins have no core code in them. > everyone has to add-on to PCB... Right. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
On Tue, May 26, 2009 at 9:53 PM, DJ Delorie wrote: > >> How do you do: >> gcc -c swig_wrapper.c >> gcc -shared pcb swig_wrapper.o -o swig_pcb.so >> without gcc cursing at you? > > %.so : %.c > gcc $(INCLUDES) -g -O2 -Wall -shared $< -o $@ > This creates DYN objects for each .c file, the objects created during PCB's current build are REL not DYN... The goal was to have PCB and the bindings not have duplicate object code... which a shared library would solve. > Shared libraries can have cyclic dependencies with the app that loads > them. You don't link against the app, though. > True, but this is a different case where the app is not the one loading the bindings... and the functions at the core of the executable need to be accessed. Hence a shared library with those core functions would allow the bindings and app to not duplicate code. It looks like Igor's hid extension gets around this by the app loading the extension which then provides access to the core functions to the scripting language. Lots of middlemen that aren't really needed for bindings. I think I'm starting to understand my misconception, instead of PCB being an architecture having core technology (e.g. auto routing, etc...) that could be used by and expandable into other programs, everyone has to add-on to PCB... I was thinking of it the other way around. Oh, well. Jason ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
> How do you do: >gcc -c swig_wrapper.c >gcc -shared pcb swig_wrapper.o -o swig_pcb.so > without gcc cursing at you? %.so : %.c gcc $(INCLUDES) -g -O2 -Wall -shared $< -o $@ Shared libraries can have cyclic dependencies with the app that loads them. You don't link against the app, though. > And taken further if you want to access all the functions that the > PCB core provides you have to link against all of the object files. Um, no? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
On Tue, May 26, 2009 at 9:24 PM, DJ Delorie wrote: > >> but the bindings would require all of the same object files that >> would be in a shared library. > > You'll have to explain that further. The main application *is* a > shared object (else dynamic plugin loading wouldn't work), why do we > need to separate out parts of it into a second shared object? > How do you do: gcc -c swig_wrapper.c gcc -shared pcb swig_wrapper.o -o swig_pcb.so without gcc cursing at you? Now if you wanted to access all of the functions in a particular object file, you could: gcc -c swig_wrapper.c file.c gcc -shared swig_wrapper.o file.o -o swig_wrapper.so And taken further if you want to access all the functions that the PCB core provides you have to link against all of the object files. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
Jason Childs wrote: > On Tue, May 26, 2009 at 8:38 PM, John Griessen wrote: >> To control drawing tools via a plugin in any language >> Igor/Tibor's GPMI interface allows would be fabulous! Think of all the >> extra efforts >> that people would make in all their different favorite scripting languages? >> Just like SWIG, and we already have it. > > Do you have a working link to the GPMI hid? I can't seem to find any that > work. I"m busy with ordinary survival, (way beyond Cosmodamiansk Россия levels, but not very flashy per Austin TX), and have not tested it yet. > >> What are you working on? Why not try those ideas on us? >> > > Because I would get flamed... :) > http://github.com/oblivian/geda-xml/tree/master Oh... more on my to do list... Can't promise. XML is OK by me. Like DJ said. JG -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
> but the bindings would require all of the same object files that > would be in a shared library. You'll have to explain that further. The main application *is* a shared object (else dynamic plugin loading wouldn't work), why do we need to separate out parts of it into a second shared object? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
On Tue, May 26, 2009 at 8:00 PM, DJ Delorie wrote: > Except that PCB is an application, not a library. If swig assumes the > target is a library (I don't think it does), perhaps that means that > swig is a bad choice? Or perhaps you could change the way you're > trying to use it? As soon as we split out a library, we have to start > worrying about compatibility across releases, which is a pain. > You're right, swig does not assume the target is a library, but the bindings would require all of the same object files that would be in a shared library. Which is why I'm suggesting a shared library. Jason ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
> Do you have a working link to the GPMI hid? I can't seem to find any > that work. Igor should be able to provide one ;-) > Because I would get flamed... :) > http://github.com/oblivian/geda-xml/tree/master I have no problem with people writing extensions to read/write XML for pcb. What I'm opposed to is using XML for pcb's native file format or core internals. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
On Tue, May 26, 2009 at 8:38 PM, John Griessen wrote: > To control drawing tools via a plugin in any language > Igor/Tibor's GPMI interface allows would be fabulous! Think of all the extra > efforts > that people would make in all their different favorite scripting languages? > Just like SWIG, and we already have it. Do you have a working link to the GPMI hid? I can't seem to find any that work. > > What are you working on? Why not try those ideas on us? > Because I would get flamed... :) http://github.com/oblivian/geda-xml/tree/master Jason ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
DJ Delorie wrote: if we're putting that much work > into the core design of pcb, I'd rather shoot for a bigger prize than > just "support swig". For example, I'd like to redo how drawing tools > and board objects are handled internally so we can extend those with > plugins as well. I'd like board objects to be searched through by any attrib down to what is atomic for chip design even, since PCB may soon be used for organic printable circuits much like chip design tools are. ??Gnetman might plug in to pcb some day if we modularize it enough?? -- gnetman promises large scale database speed handling of millions of objects, (not needed yet). To control drawing tools via a plugin in any language Igor/Tibor's GPMI interface allows would be fabulous! Think of all the extra efforts that people would make in all their different favorite scripting languages? Just like SWIG, and we already have it. Jason Childs wrote: > The real point of the patch was that I want to create swig bindings > for pcb and libgeda in support of another geda subproject I'm working > on. What are you working on? Why not try those ideas on us? John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
> hid plugins can be built without the whole source tree. We can already do that. Heck, it's been done, too - Igor added an interpreter engine much like what swig does, which supports writing interpreted HIDs. > The real point of the patch was that I want to create swig bindings > for pcb and libgeda in support of another geda subproject I'm working > on. To do that I really need a library to build the bindings against. Except that PCB is an application, not a library. If swig assumes the target is a library (I don't think it does), perhaps that means that swig is a bad choice? Or perhaps you could change the way you're trying to use it? As soon as we split out a library, we have to start worrying about compatibility across releases, which is a pain. > Admittedly, there is more work that needs to be done to properly > separate the pcb executable from the libpcb library and provide some > more API coherency. > > I'm willing to do that, Doing it right is a lot of work, and if we're putting that much work into the core design of pcb, I'd rather shoot for a bigger prize than just "support swig". For example, I'd like to redo how drawing tools and board objects are handled internally so we can extend those with plugins as well. We've also gotten many requests for enhancements to the board layout, which would require design changes. Formalizing an API would make it more difficult to make those changes, if only because people would complain when you change the API. Plus, you'd still have to convince us that we need a "libpcb". ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
DJ, Not really the point of the patch, just an added benefit in my opinion. It also cleans up the Makefiles. Beyond that, by providing a shared library and header files for installation, hid plugins can be built without the whole source tree. Ubuntu and other distros can now have a pcb-dev package that allows hid plugins to be developed. The real point of the patch was that I want to create swig bindings for pcb and libgeda in support of another geda subproject I'm working on. To do that I really need a library to build the bindings against. Admittedly, there is more work that needs to be done to properly separate the pcb executable from the libpcb library and provide some more API coherency. I'm willing to do that, and it may be better if I just host a git repository that can be pulled from as I make changes. (I think gmail hacked up the patches I submitted anyway). Jason On Mon, May 25, 2009 at 9:04 PM, DJ Delorie wrote: > > Do we really need all the complexity of libtool and shared libraries > just to avoid editing a file? > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
Do we really need all the complexity of libtool and shared libraries just to avoid editing a file? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: pcb library and hid build modification
For your consideration...
I've incorporated a libtool based library from the PCB sources, and
each HID is now created with libtool as static archives using their
own Makefiles. I hope this will make it easier to incorporate new
HID's in the future since it keeps you from editing a single
makefile. New HIDs should only require copying an existing HID
directory and modifying the Makefile which should be picked up from
the rest of the Makefile hierarchy. You will still need to add the
HID makefile to the [1]configure.ac file for automake creation though,
but that should be it.
This also separates the pcb executable from the "core" files and
creates a libpcb.so file that the main.c is linked against to create
the pcb executable.
I'm working on python bindings for both libgeda and pcb so this was
the "easiest" way I could think of to get access to the pcb functions
for export. This may have added benifit allowing for easier combining
of libgeda and libpcb in the future as well if desired.
Compiles cleanly and works on Ubuntu. Tried not to break the WIN32
code, but have no way to test.
Jason
References
1. http://configure.ac/
diff --git a/autogen.sh b/autogen.sh
index d1671fb..9a8f624 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -11,6 +11,25 @@ export CONFIG_SHELL
#
+# libtoolize
+#
+
+echo "Checking for libtoolize..."
+# Possible names for libtool/libtoolize
+libtoolize_candidates="libtoolize glibtoolize"
+
+LIBTOOLIZE=`which $libtoolize_candidates 2>/dev/null | head -n1`
+(! test -z "$LIBTOOLIZE") || {
+ echo
+ echo "**Error**: You must have \`libtool' installed."
+ echo "You can get it from: ftp://ftp.gnu.org/pub/gnu/";
+ DIE=1
+}
+echo "Running libtoolize..."
+$LIBTOOLIZE --force --copy || exit 1
+
+
+#
# autopoint (gettext)
#
diff --git a/configure.ac b/configure.ac
index 08fcd6e..45be377 100644
--- a/configure.ac
+++ b/configure.ac
@@ -10,6 +10,11 @@ AM_CONFIG_HEADER([config.h])
AM_MAINTAINER_MODE
+dnl Initialize libtool
+AC_LIBTOOL_WIN32_DLL
+AM_PROG_LIBTOOL
+AC_CONFIG_MACRO_DIR([m4])
+
dnl determine host type
AC_CANONICAL_HOST
AC_MSG_CHECKING(for windows)
@@ -93,7 +98,6 @@ ftp://ftp.gnu.org/pub/gnu/bison/
fi
AC_PROG_INSTALL
-AC_PROG_RANLIB
#
# Used for building the icons
@@ -349,8 +353,10 @@ for hid in $HIDLIST; do
fi
done
-for e in $HIDLIST; do
-HIDLIBS="$HIDLIBS lib$e.a"
+AC_MSG_RESULT([Processing all enabled HIDs])
+for hid in $HIDLIST; do
+ AC_MSG_RESULT([Adding $hid as _hid_$hid.la])
+ HIDLIBS="$HIDLIBS hid/$hid/_hid_$hid.la"
done
AC_SUBST(HIDLIST)
@@ -925,6 +931,18 @@ if test -d $srcdir/newlib; then
AC_CONFIG_FILES(newlib/tests/Makefile)
fi
AC_CONFIG_FILES(src/Makefile)
+AC_CONFIG_FILES(src/hid/Makefile)
+AC_CONFIG_FILES(src/hid/batch/Makefile)
+AC_CONFIG_FILES(src/hid/bom/Makefile)
+AC_CONFIG_FILES(src/hid/common/Makefile)
+AC_CONFIG_FILES(src/hid/gerber/Makefile)
+AC_CONFIG_FILES(src/hid/gtk/Makefile)
+AC_CONFIG_FILES(src/hid/lesstif/Makefile)
+AC_CONFIG_FILES(src/hid/lpr/Makefile)
+AC_CONFIG_FILES(src/hid/nelma/Makefile)
+AC_CONFIG_FILES(src/hid/png/Makefile)
+AC_CONFIG_FILES(src/hid/ps/Makefile)
+AC_CONFIG_FILES(src/gts/Makefile)
AC_CONFIG_FILES(src/icons/Makefile)
if test -d $srcdir/tools; then
AC_CONFIG_FILES(tools/Makefile)
diff --git a/src/Makefile.am b/src/Makefile.am
index ebff648..cb0dcf4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -2,24 +2,18 @@
## $Id$
##
-SUBDIRS= icons
+SUBDIRS = hid gts icons
-pcbtreedir= @PCBTREEDIR@
-pcblibdir= @PCBLIBDIR@
+pcblibdir = @PCBLIBDIR@
AUTOMAKE_OPTIONS = subdir-objects
-HIDLIST = @HIDLIST@
-noinst_LIBRARIES = @HIDLIBS@
-EXTRA_LIBRARIES = \
- libgtk.a liblesstif.a libbatch.a \
- liblpr.a libgerber.a libbom.a libpng.a libps.a libnelma.a libgts.a
-
-pcblib_DATA= \
+pcblib_DATA = \
default_font \
gpcb-menu.res \
pcb-menu.res
-bin_PROGRAMS= pcb
+bin_PROGRAMS = pcb
+lib_LTLIBRARIES = libpcb.la
if DEBUG_BUILD
# don't disable assert()
@@ -27,193 +21,96 @@ else
AM_CFLAGS = -DNDEBUG
endif
-PCB_SRCS = \
+libpcb_la_SOURCES = \
action.c \
- action.h \
autoplace.c \
- autoplace.h \
autoroute.c \
- autoroute.h \
- box.h \
buffer.c \
- buffer.h \
change.c \
- change.h \
clip.c \
- clip.h \
command.c \
- command.h \
compat.c \
- compat.h \
- const.h \
copy.c \
- copy.h \
create.c \
- create.h \
crosshair.c \
- crosshair.h \
data.c \
- data.h \
djopt.c \
- djopt.h \
- dolists.h \
draw.c \
- draw.h \
drill.c \
- drill.h \
edif.y \
- edif_parse.h \
error.c \
- error.h \
file.c \
- file.h \
find.c \
- find.h \
flags.c \
fontmode.c \
- global.h \
heap.c \
- heap.h \
- hid.h \
insert.c \
- insert.h \
intersect.c \
- intersect.h \
line.c \
- line.h \
lrealpath.c \
- lrealpath.h \
- macro.h \
- main.c \
mirror.c
