Re: gEDA-user: gEDA just hit SlashDotOrg
On Sun, Aug 2, 2009 at 8:42 AM, John Dotyj...@noqsi.com wrote: We're not a programming team implementing what Marketing wants. We're a bunch of computer-savvy users implementing what we intend to use. That's our strength. That's why gEDA is different. That's why gEDA is a sharp toolkit for the computer-savvy. So is this why my simple bsearch patch for hid's hasn't been incorporated in 3 months? I have to apply it every time I do a pull from pcb git so that it doesn't segfault. I'm sorry, but the tone as of late on the mailing list has been our way or the highway, at least from what I've read and encountered on the mailing list. Heck I've been afraid to post using gMail for fear of getting kicked from the mailing list because of double posting or posting in RTF. Frankly if you can't see the current problems within the geda community that's ashame, because it's a reflection of the product too and why thing's haven't advanced. The code base needs some serious refactoring to advance and you need a programming team to do that work, not users, however savvy they are. I thought when I converted the gaf source from using noweb it would open up a whole new opportunity for actual software developers to start contributing, and I now regret the time I lost doing it. ___ 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 d...@delorie.com 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
On Tue, May 26, 2009 at 8:38 PM, John Griessen j...@ecosensory.com 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
On Tue, May 26, 2009 at 8:00 PM, DJ Delorie d...@delorie.com 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
On Tue, May 26, 2009 at 9:24 PM, DJ Delorie d...@delorie.com 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
On Tue, May 26, 2009 at 9:53 PM, DJ Delorie d...@delorie.com 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
On Tue, May 26, 2009 at 11:05 PM, DJ Delorie d...@delorie.com 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: system-gafrc
Peter, Here's the one I have... Jason On Mon, May 25, 2009 at 6:02 PM, Peter Gregson [1]peter.greg...@dal.ca wrote: Hi, All, I have had endless trouble trying to install geda-bundle on my Intel MacBook running 10.5.7. It appears that all installs properly except that I don't have system-gafrc installed in /sw/etc/gEDA. Can someone send me a copy so that I can place it there? This shows up when I try to run gschem. My geda-bundle contains gschem 1.4.3.20081231 Thanks, and Best regards Peter Peter Gregson, Ph.D., P.Eng. Professor, ECE ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:peter.greg...@dal.ca 2. mailto:geda-user@moria.seul.org 3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user system-gafrc Description: Binary data ___ 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 \
- mirror.h \
