[ptxdist] install vs. targetinstall
Hi, I'm quite new to ptxdist and I have not found true meaning of the install nor the targetinstall step. Can someone explain me the background of those two steps (or point me to some more documentation about it). Thanks. Bart -- -- Bart De Vos Development Engineer mailto:[EMAIL PROTECTED] EIA Electronics Vluchtenburgstraat 3 B-2630 Aartselaar (Belgium) phone : +32(0)3 870 85 29 fax : +32(0)3 877 14 72 website : http://www.eia.be/ -- Basically, perfect development is impossible. Development can be fast, good and cheap. Pick two! — Larry Wall -- -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] gsl-1.11 package
Hello,
Hereby I send the files to include GNU's Scientific Library, including
patches.
tested with crosscompilers from the ct-ng package
(http://ymorin.is-a-geek.org/dokuwiki/projects/crosstool) with the
following config:
binutils:2.18.50.0.8
gcc-4.3.1
glibc-2.6.1
nptl
crosscompilers used are:
arm-x-linux-gnueabi
powerpc-x-linux-gnu
i686-x-linux-gnu
kind regards,
Bart.
--
--
Bart De Vos
Development Engineer
mailto:[EMAIL PROTECTED]
EIA Electronics
Vluchtenburgstraat 3
B-2630 Aartselaar (Belgium)
phone : +32(0)3 870 85 29
fax : +32(0)3 877 14 72
website : http://www.eia.be/
--
Basically, perfect development is impossible.
Development can be fast, good and cheap. Pick two!
— Larry Wall
--
--- gsl-1.11/configure 2008-09-11 13:05:27.0 +0200
+++ gsl-1.11-ptx/configure 2008-09-11 13:05:39.0 +0200
@@ -12578,7 +12578,8 @@
See \`config.log' for more details." >&5
echo "$as_me: error: cannot run test program while cross compiling
See \`config.log' for more details." >&2;}
- { (exit 1); exit 1; }; }
+# { (exit 1); exit 1; };
+ }
else
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h. */
config LIBGSL
bool
prompt "libgsl"
help
GNU Scientific Library
# -*-makefile-*-
# $Id: template 6655 2007-01-02 12:55:21Z rsc $
#
# Copyright (C) 2008 by info-gsl
#
# See CREDITS for details about who has contributed to this project.
#
# For further information about the PTXdist project and license conditions
# see the README file.
#
#
# We provide this package
#
PACKAGES-$(PTXCONF_LIBGSL) += libgsl
#
# Paths and names
#
LIBGSL_VERSION := 1.11
LIBGSL := gsl-$(LIBGSL_VERSION)
LIBGSL_SUFFIX := tar.gz
ifdef PTXCONF_SETUP_GNUMIRROR
LIBGSL_URL :=
$(PTXCONF_SETUP_GNUMIRROR)/gsl/$(LIBGSL).$(LIBGSL_SUFFIX)
else
LIBGSL_URL :=
ftp://ftp.gnu.org/gnu/gsl/$(LIBGSL).$(LIBGSL_SUFFIX)
endif
LIBGSL_SOURCE := $(SRCDIR)/$(LIBGSL).$(LIBGSL_SUFFIX)
LIBGSL_DIR := $(BUILDDIR)/$(LIBGSL)
#
# Get
#
libgsl_get: $(STATEDIR)/libgsl.get
$(STATEDIR)/libgsl.get: $(libgsl_get_deps_default)
@$(call targetinfo, $@)
@$(call touch, $@)
$(LIBGSL_SOURCE):
@$(call targetinfo, $@)
@$(call get, LIBGSL)
#
# Extract
#
libgsl_extract: $(STATEDIR)/libgsl.extract
$(STATEDIR)/libgsl.extract: $(libgsl_extract_deps_default)
@$(call targetinfo, $@)
@$(call clean, $(LIBGSL_DIR))
@$(call extract, LIBGSL)
@$(call patchin, LIBGSL)
@$(call touch, $@)
#
# Prepare
#
libgsl_prepare: $(STATEDIR)/libgsl.prepare
LIBGSL_PATH := PATH=$(CROSS_PATH)
LIBGSL_ENV := $(CROSS_ENV)
#
# autoconf
#
LIBGSL_AUTOCONF := $(CROSS_AUTOCONF_USR)
$(STATEDIR)/libgsl.prepare: $(libgsl_prepare_deps_default)
@$(call targetinfo, $@)
@$(call clean, $(LIBGSL_DIR)/config.cache)
cd $(LIBGSL_DIR) && \
$(LIBGSL_PATH) $(LIBGSL_ENV) \
./configure $(LIBGSL_AUTOCONF)
@$(call touch, $@)
#
# Compile
#
libgsl_compile: $(STATEDIR)/libgsl.compile
$(STATEDIR)/libgsl.compile: $(libgsl_compile_deps_default)
@$(call targetinfo, $@)
cd $(LIBGSL_DIR) && $(LIBGSL_ENV) $(LIBGSL_PATH) $(MAKE)
$(PARALLELMFLAGS)
@$(call touch, $@)
#
# Install
#
libgsl_install: $(STATEDIR)/libgsl.install
$(STATEDIR)/libgsl.install: $(libgsl_install_deps_default)
@$(call targetinfo, $@)
@$(call install, LIBGSL)
@$(call touch, $@)
#
# Target-Install
#
libgsl_targetinstall: $(STATEDIR)/libgsl.targetinstall
$(STATEDIR)/libgsl.targetinstall: $(libgsl_targetinstall_deps_default)
@$(call targetinfo, $@)
@$(call install_init, libgsl)
@$(call install_fixup, libgsl,PACKAGE,libgsl)
@$(call install
Re: [ptxdist] gsl-1.11 package
Robert Schwebel wrote: Bart, On Thu, Sep 11, 2008 at 01:40:46PM +0200, Bart De Vos wrote: Hereby I send the files to include GNU's Scientific Library, including patches. [...] @$(call install_fixup, libgsl,AUTHOR,"Robert Schwebel <[EMAIL PROTECTED]>") @$(call install_fixup, libgsl,DEPENDS,) @$(call install_fixup, libgsl,DESCRIPTION,missing) # -*-makefile-*- # $Id: template 6655 2007-01-02 12:55:21Z rsc $ # # Copyright (C) 2008 by info-gsl # # See CREDITS for details about who has contributed to this project. # # For further information about the PTXdist project and license conditions # see the README file. # # # We provide this package # PACKAGES-$(PTXCONF_LIBGSL) += libgsl # # Paths and names # LIBGSL_VERSION := 1.11 LIBGSL := gsl-$(LIBGSL_VERSION) LIBGSL_SUFFIX := tar.gz ifdef PTXCONF_SETUP_GNUMIRROR LIBGSL_URL := $(PTXCONF_SETUP_GNUMIRROR)/gsl/$(LIBGSL).$(LIBGSL_SUFFIX) else LIBGSL_URL := ftp://ftp.gnu.org/gnu/gsl/$(LIBGSL).$(LIBGSL_SUFFIX) endif LIBGSL_SOURCE := $(SRCDIR)/$(LIBGSL).$(LIBGSL_SUFFIX) LIBGSL_DIR := $(BUILDDIR)/$(LIBGSL) # # Get # libgsl_get: $(STATEDIR)/libgsl.get $(STATEDIR)/libgsl.get: $(libgsl_get_deps_default) @$(call targetinfo, $@) @$(call touch, $@) $(LIBGSL_SOURCE): @$(call targetinfo, $@) @$(call get, LIBGSL) # # Extract # libgsl_extract: $(STATEDIR)/libgsl.extract $(STATEDIR)/libgsl.extract: $(libgsl_extract_deps_default) @$(call targetinfo, $@) @$(call clean, $(LIBGSL_DIR)) @$(call extract, LIBGSL) @$(call patchin, LIBGSL) @$(call touch, $@) # # Prepare # libgsl_prepare: $(STATEDIR)/libgsl.prepare LIBGSL_PATH := PATH=$(CROSS_PATH) LIBGSL_ENV := $(CROSS_ENV) # # autoconf # LIBGSL_AUTOCONF := $(CROSS_AUTOCONF_USR) $(STATEDIR)/libgsl.prepare: $(libgsl_prepare_deps_default) @$(call targetinfo, $@) @$(call clean, $(LIBGSL_DIR)/config.cache) cd $(LIBGSL_DIR) && \ $(LIBGSL_PATH) $(LIBGSL_ENV) \ ./configure $(LIBGSL_AUTOCONF) @$(call touch, $@) # # Compile # libgsl_compile: $(STATEDIR)/libgsl.compile $(STATEDIR)/libgsl.compile: $(libgsl_compile_deps_default) @$(call targetinfo, $@) cd $(LIBGSL_DIR) && $(LIBGSL_ENV) $(LIBGSL_PATH) $(MAKE) $(PARALLELMFLAGS) @$(call touch, $@) # # Install # libgsl_install: $(STATEDIR)/libgsl.install $(STATEDIR)/libgsl.install: $(libgsl_install_deps_default) @$(call targetinfo, $@) @$(call install, LIBGSL) @$(call touch, $@) # # Target-Install # libgsl_targetinstall: $(STATEDIR)/libgsl.targetinstall $(STATEDIR)/libgsl.targetinstall: $(libgsl_targetinstall_deps_default) @$(call targetinfo, $@) @$(call install_init, libgsl) @$(call install_fixup, libgsl,PACKAGE,libgsl) @$(call install_fixup, libgsl,PRIORITY,optional) @$(call install_fixup, libgsl,VERSION,$(LIBGSL_VERSION)) @$(call install_fixup, libgsl,SECTION,base) @$(call install_fixup, libgsl,AUTHOR,"Bart De Vos <[EMAIL PROTECTED]>") @$(call install_fixup, libgsl,DEPENDS,) @$(call install_fixup, libgsl,DESCRIPTION,"The GNU Scientific Library (GSL) is a numerical library for C and C++ programmers") @$(call install_copy, libgsl, 0, 0, 0644, \ $(LIBGSL_DIR)/.libs/libgsl.so.0.12.0, \ /usr/lib/libgsl.so.0.12.0, "strip") @$(call install_link, libgsl, libgsl.so.0.12.0, /usr/lib/libgsl.so.0) @$(call install_link, libgsl, libgsl.so.0.12.0, /usr/lib/libgsl.so) @$(call install_copy, libgsl, 0, 0, 0644, \ $(LIBGSL_DIR)/gsl-config, \ /usr/bin/gsl-config, "no") @$(call install_copy, libgsl, 0, 0, 0644, \ $(LIBGSL_DIR
[ptxdist] generated Kconfig files ?
Hello, In an attempt to migrate from ptxdist 1.99.5 to 1.99.19.1 i ran into the following problems: -- ptxdist migrate info: successfully migrated '/opt/eia/build/ptxdist-1.99.19.1/selected_ptxconfig' config/Kconfig:12: can't open file "generated/fixme.in" ptxdist: 'ptx oldconfig' returned with an error -- This is what i did: download 1.99.19.1 and 1.99.19.1-patches and extract into dir /opt/ptxdist-new cd /opt/ptxdist-new && configure --prefix=/opt/ptxdist-new && make sudo make install cp /opt/ptxdist/ptxconfig /opt/ptxdist-new cp /opt/ptxdist/platformconfig /opt/ptxdist-new ptxdist select ptxconfig ptxdist platform platformconfig ptxdist toolchain /path/to/compiler/bin ptxdist migrate A search on 'generated' tells me that some part of the Kconfig is now generated. How? Can someone clear this out please? Kind regards. -- -- Bart De Vos Development Engineer mailto:bart.de...@eia.be EIA Electronics Vluchtenburgstraat 3 B-2630 Aartselaar (Belgium) phone : +32(0)3 870 85 29 fax : +32(0)3 877 14 72 website : http://www.eia.be/ -- Basically, perfect development is impossible. Development can be fast, good and cheap. Pick two! — Larry Wall -- -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Qt and mini2440 BSP
Hello, I found similar problems during backporting Qt4 to ptxdist 1.99 series. I believe the trick is to do a 'make uninstall' for qt. In my case the 'clean' step in rules/qt4.make looks as this: # # Clean # qt4_clean: rm -rf $(STATEDIR)/qt4.* rm -rf $(PKGDIR)/qt4_* @cd $(QT4_DIR) && $(QT4_PATH) $(MAKE) uninstall rm -rf $(QT4_DIR) If you do a 'ptxdist clean qt4' the sysroot is also cleaned allowing you to use a proper build. I also believe that running the 'uninstall' step is a good thing to do in other packages as well. Kind regards, Bart. On 07/05/2011 09:50 AM, MC Potgieter wrote: I also had some strange behavior after changing settings for Qt. I also had to start from scratch to restore order. Does this mean Arora is now working? On Tue, Jul 5, 2011 at 9:12 AM, Dave <mailto:dave_fest...@hotmail.com>> wrote: Qt problems on PTXdist 06 After a compilation of my "own" Qt project (/demos/browser), following instructions posted and adding another mouse driver in Qt things started to go wrong. My efforts to restore proper operation consisted of doing the following: $ ptxdist clean browser $ ptxdist clean qt4 $ ptxdist clean root then $ ptxdist go deleting the four "unwanted" .qmake.cache files in build-host/qt-everywhere-opensource-src-4.6.3-build build-host/qt-everywhere-opensource-src-4.6.3-build/config.test build-target/qt-everywhere-opensource-src-4.6.3-build build-target/qt-everywhere-opensource-src-4.6.3-build/config.test then $ ptxdist go deleting folders build-host/qt-everywhere-opensource-src-4.6.3-build build-host/qt-everywhere-opensource-src-4.6.3-src build-target/qt-everywhere-opensource-src-4.6.3-build build-target/qt-everywhere-opensource-src-4.6.3-src then $ ptxdist go A common error message was: /home/davef/Pengutronix-6/OSELAS.BSP-Pengutronix-Mini2440-2011.06.0/ platform-mini2440/sysroot-target/usr/lib/ libQtCore.a(qlibrary_unix.o): In function `qdlerror()': qlibrary_unix.cpp:(.text+0x88): undefined reference to `dlerror' . /opt/OSELAS.Toolchain-2011.03.0/arm-v4t-linux-gnueabi/ gcc-4.5.2-glibc-2.13-binutils-2.21-kernel-2.6.36-sanitized/lib/gcc/ arm-v4t-linux-gnueabi/4.5.2/../../../../arm-v4t-linux-gnueabi/bin/ ld: warning: creating a DT_TEXTREL in object. collect2: ld returned 1 exit status make[2]: Leaving directory `/home/davef/Pengutronix-6/ OSELAS.BSP-Pengutronix-Mini2440-2011.06.0/platform-mini2440/build-target/ qt-everywhere-opensource-src-4.6.3-build/src/network' make[1]: Leaving directory `/home/davef/Pengutronix-6/ OSELAS.BSP-Pengutronix-Mini2440-2011.06.0/platform-mini2440/build-target/ qt-everywhere-opensource-src-4.6.3-build' make[2]: *** [../../lib/libQtNetwork.so.4.6.3] Error 1 make[1]: *** [sub-network] Error 2 make: *** [/home/davef/Pengutronix-6/ OSELAS.BSP-Pengutronix-Mini2440-2011.06.0/platform-mini2440/ state/qt4.compile] Error 2 davef@davef-desktop:~/Pengutronix-6/OSELAS.BSP-Pengutronix-Mini2440-2011.06.0$ I suspect this is possibly the first instance of a Qt library being cross-compiled. Next, I deleted OSELAS.BSP-Pengutronix-Mini2440-2011.06.0 and started over again. This time I checked basic kernel operation and then added Qt and the Qt options to support Arora. Having previously cross-compiled /demos/browser using the PTXdist toolchain I just dropped it's binary into /usr/bin and the program runs properly. So, the question is how should one reclaim a BSP after it has obviously been corrupted because of failed attempts at cross-compiling Qt? -- ptxdist mailing list ptxdist@pengutronix.de <mailto:ptxdist@pengutronix.de> -- -- Bart De Vos Development Engineer mailto:bart.de...@eia.be EIA Electronics Vluchtenburgstraat 3 B-2630 Aartselaar (Belgium) phone : +32(0)3 870 85 29 fax : +32(0)3 877 14 72 website : http://www.eia.be/ -- Basically, perfect development is impossible. Development can be fast, good and cheap. Pick two! --- Larry Wall -- -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Qt and mini2440 BSP
Dave, @$(call clean, $(QT4_DIR)) will execute: (from a conceptual point of view) cd QT4_DIR && make clean whereas my addition will execute: cd QT4_DIR && make uninstall which is _not_ the same. Also take the moment of execution into consideration. My addition is _only_ exectuted if you call: "ptxdist clean qt4" whereas the $(call clean, ...) is executed somewhere in the build process (i.e. in the 'extract' step). Last but not least, I'm still using ptxdist 1.99.5 which is older. I believe some things have been changed regarding cleaning packages. My patch will only 'uninstall' qt4 from the sysroot and nothing more. If that was what you're looking for, you can use it. If that is not what you're looking for; then what are you looking for? I needed the patch in the situation where I changed from "qt-static only" to "qt with shared libraries" (or visa versa). In that case some libs were still available in the sysroot (from the previous built) causing some troubles. Hopefully that clarifies one and another. Kind regards, Bart. On 07/12/2011 11:54 AM, Dave wrote: Bart, With regard to a more thorough clean of Qt apps . . . >In my case the > 'clean' step in rules/qt4.make looks as this: > # > > # Clean > # > > qt4_clean: > rm -rf $(STATEDIR)/qt4.* > rm -rf $(PKGDIR)/qt4_* > cd $(QT4_DIR)&& $(QT4_PATH) $(MAKE) uninstall > rm -rf $(QT4_DIR) Are suggesting replacing the line: @$(call clean, $(QT4_DIR)) here, in the original script: $(STATEDIR)/qt4.extract: @$(call targetinfo) @$(call clean, $(QT4_DIR)) @$(call extract, QT4) @$(call patchin, QT4) with the above or just adding your change? Thank you, Dave -- ptxdist mailing list ptxdist@pengutronix.de -- -- Bart De Vos Development Engineer mailto:bart.de...@eia.be EIA Electronics Vluchtenburgstraat 3 B-2630 Aartselaar (Belgium) phone : +32(0)3 870 85 29 fax : +32(0)3 877 14 72 website : http://www.eia.be/ -- Basically, perfect development is impossible. Development can be fast, good and cheap. Pick two! — Larry Wall -- -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] General Ptxdist usecase question
Hello, We have some kind of similar setup in which we split our root file system and the customers filesystem. In runtime the customers filesystem is mounted on a fixed point (/opt). Off-course we have designed this separation from the start, we have 2 separated filesystems. For the second filesystem you can use just another ptxdist configfile. I don't know whether you can merge 2 file system images together with ptxdist. But for this purpose a simple script can automate this. Another approach can be to support a list of configfiles in stead of only one. This will give you a single image file which was what you 'v been asking for in the first place. Are there any plans to support a list of configfiles? Kind regards, Bart. On 10/28/2011 10:21 AM, Erwin Rol wrote: Hey all, The projects I use Ptxdist for have grown in size over the last few years, they now include mono, gtkwebkit, boost, clutter, gtk3 and all the Xorg stuff. That means it now takes more than 2 hours to compile it from scratch. The machine is not the fastest (only 4 core 3GHz) but even if it was twice as fast it would still compile over and hour. So I am looking for a way to prevent a full rebuild on every project release. There seem to be some features in Ptxdist that should allow this, but I could not really figure out how to use them. What I would like to do is this; 1) Build an OS with all the Xorg, mono, gtk, etc. stuff and version that. 2) build my own applications. 3) combine the results from step 1 and 2 into an image for flashing 4) goto 2 Is it possible to do this with Ptxdist and if so, how ? TIA, Erwin -- ------ Bart De Vos Development Engineer mailto:bart.de...@eia.be EIA Electronics Vluchtenburgstraat 3 B-2630 Aartselaar (Belgium) phone : +32(0)3 870 85 29 fax : +32(0)3 877 14 72 website : http://www.eia.be/ -- Basically, perfect development is impossible. Development can be fast, good and cheap. Pick two! — Larry Wall -- -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] General Ptxdist usecase question
Hallo Erwin, On 10/28/2011 10:46 AM, Erwin Rol wrote: Hallo Bart, On 28-10-2011 10:38, Bart De Vos wrote: Hello, We have some kind of similar setup in which we split our root file system and the customers filesystem. In runtime the customers filesystem is mounted on a fixed point (/opt). Off-course we have designed this separation from the start, we have 2 separated filesystems. For the second filesystem you can use just another ptxdist configfile. I don't know whether you can merge 2 file system images together with ptxdist. But for this purpose a simple script can automate this. That would be an option too. I could easily deal with 2 filesystems. But how do you build the second (user) project? It seems you need to duplicate almost all settings in the second config file. And that is very error prone in my eyes. To be honest, today we don't build the second system with PTXdist, but we might do that in the future. I agree with you: duplication is error prone. I don't see where the duplication comes from. On the other hand the root filesystem must be able to start services from the second filesystem. (call a script upon mounting) Another approach can be to support a list of configfiles in stead of only one. This will give you a single image file which was what you 'v been asking for in the first place. Shouldn't it already be possible to do something like this; OS project create ptxdistconfig and platformconfig Than in the user project include the OS ptxdistconfig and platformconfig. But how to tell the user project not to rebuild everything again. That's my main problem. I don't have an answer on that, sorry. - Erwin /Bart. Are there any plans to support a list of configfiles? Kind regards, Bart. On 10/28/2011 10:21 AM, Erwin Rol wrote: Hey all, The projects I use Ptxdist for have grown in size over the last few years, they now include mono, gtkwebkit, boost, clutter, gtk3 and all the Xorg stuff. That means it now takes more than 2 hours to compile it from scratch. The machine is not the fastest (only 4 core 3GHz) but even if it was twice as fast it would still compile over and hour. So I am looking for a way to prevent a full rebuild on every project release. There seem to be some features in Ptxdist that should allow this, but I could not really figure out how to use them. What I would like to do is this; 1) Build an OS with all the Xorg, mono, gtk, etc. stuff and version that. 2) build my own applications. 3) combine the results from step 1 and 2 into an image for flashing 4) goto 2 Is it possible to do this with Ptxdist and if so, how ? TIA, Erwin -- ---------- Bart De Vos Development Engineer mailto:bart.de...@eia.be EIA Electronics Vluchtenburgstraat 3 B-2630 Aartselaar (Belgium) phone : +32(0)3 870 85 29 fax : +32(0)3 877 14 72 website : http://www.eia.be/ -- Basically, perfect development is impossible. Development can be fast, good and cheap. Pick two! — Larry Wall -- -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] General Ptxdist usecase question
On 10/28/2011 11:33 AM, Michael Olbrich wrote: Hi, On Fri, Oct 28, 2011 at 10:38:00AM +0200, Bart De Vos wrote: We have some kind of similar setup in which we split our root file system and the customers filesystem. In runtime the customers filesystem is mounted on a fixed point (/opt). Off-course we have designed this separation from the start, we have 2 separated filesystems. For the second filesystem you can use just another ptxdist configfile. I don't know whether you can merge 2 file system images together with ptxdist. But for this purpose a simple script can automate this. If the second file system is available as a tar-ball you can do: @$(call install_archive, otherfs, -, -, \ $(PTXDIST_WORKSPACE)/local_src/otherfs.tar.gz, /) Another approach can be to support a list of configfiles in stead of only one. This will give you a single image file which was what you 'v been asking for in the first place. Are there any plans to support a list of configfiles? I don't understand what you mean with this. In the project directory I have a symlink 'selected_ptxconfig'. This points to only one file. Is it possible to have this separated in more than one file, for example let 'selected_ptxconfig' point to a directory and use all the files in there. Hope that's clear. Michael /Bart. -- ---------- Bart De Vos Development Engineer mailto:bart.de...@eia.be EIA Electronics Vluchtenburgstraat 3 B-2630 Aartselaar (Belgium) phone : +32(0)3 870 85 29 fax : +32(0)3 877 14 72 website : http://www.eia.be/ -- Basically, perfect development is impossible. Development can be fast, good and cheap. Pick two! — Larry Wall -- -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] General Ptxdist usecase question
On 10/28/2011 11:45 AM, Michael Olbrich wrote: On Fri, Oct 28, 2011 at 11:37:51AM +0200, Bart De Vos wrote: On 10/28/2011 11:33 AM, Michael Olbrich wrote: Another approach can be to support a list of configfiles in stead of only one. This will give you a single image file which was what you 'v been asking for in the first place. Are there any plans to support a list of configfiles? I don't understand what you mean with this. In the project directory I have a symlink 'selected_ptxconfig'. This points to only one file. Is it possible to have this separated in more than one file, for example let 'selected_ptxconfig' point to a directory and use all the files in there. Hope that's clear. selected_ptxconfig is usually a link to configs/ptxconfig. I have worked with BSPs where I have configs/ptxconfig-foo and configs/ptxconfig-bar. And then used whichever I needed at the moment. The question is what do you mean by "use all the files". Are they different flavours, or parts of on whole system? They can be both different flavours and individual parts of one bigger system. If this feature is supported, you can use it as you wish. Michael /Bart. -- ---------- Bart De Vos Development Engineer mailto:bart.de...@eia.be EIA Electronics Vluchtenburgstraat 3 B-2630 Aartselaar (Belgium) phone : +32(0)3 870 85 29 fax : +32(0)3 877 14 72 website : http://www.eia.be/ -- Basically, perfect development is impossible. Development can be fast, good and cheap. Pick two! — Larry Wall -- -- ptxdist mailing list ptxdist@pengutronix.de
