Menu
▾
▴
devil-linux-develop
|
From: Heiko Z. <he...@zu...> - 2010-01-05 20:01:02
|
Hey, I removed the insserv stuff for handling the script dependencies. I moved everything into Makefiles, which reside in the root of the build directory. Since I got a cold, I don't feel like too many words. So here the copy'n'paste from the changelog: - closed bug #18 - build system - replace insserv - make targets "prepare build install iso" now use makefiles automatically - new make target 'all' executes 'prepare build install iso' - remove 'makefile' and 'buildorder' targets - build order is now only controlled through the makefiles Regards Heiko Zuerker http://www.devil-linux.org |
|
From: warptrosse <war...@gm...> - 2010-01-05 20:09:58
|
This do not change the current way to compile and generate the iso? regards On Tue, Jan 5, 2010 at 5:00 PM, Heiko Zuerker <he...@zu...> wrote: > Hey, > > > > I removed the insserv stuff for handling the script dependencies. > > I moved everything into Makefiles, which reside in the root of the build > directory. > > > > Since I got a cold, I don’t feel like too many words. So here the > copy’n’paste from the changelog: > > > > - closed bug #18 - build system - replace insserv > > - make targets "prepare build install iso" now use makefiles > automatically > > - new make target 'all' executes 'prepare build install iso' > > - remove 'makefile' and 'buildorder' targets > > - build order is now only controlled through the makefiles > > > > Regards > > Heiko Zuerker > > http://www.devil-linux.org > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > -- WARPTROSSE {The knowledge of a man belongs to all the humanity} |
|
From: Heiko Z. <he...@zu...> - 2010-01-05 22:27:21
|
Hey, a tiny bit: make mrproper unpack all Or make mrproper unpack prepare build install iso The flag files for scripts which were successfully executed, moved to build/tmp/FLAGS/<phase>/<scriptname> This part is only needed if you're playing with scripts. Heiko From: warptrosse [mailto:war...@gm...] Sent: Tuesday, January 05, 2010 2:10 PM To: dev...@li... Subject: Re: [Devil-linux-develop] no more insserv in build system This do not change the current way to compile and generate the iso? regards On Tue, Jan 5, 2010 at 5:00 PM, Heiko Zuerker <he...@zu...> wrote: Hey, I removed the insserv stuff for handling the script dependencies. I moved everything into Makefiles, which reside in the root of the build directory. Since I got a cold, I don't feel like too many words. So here the copy'n'paste from the changelog: - closed bug #18 - build system - replace insserv - make targets "prepare build install iso" now use makefiles automatically - new make target 'all' executes 'prepare build install iso' - remove 'makefile' and 'buildorder' targets - build order is now only controlled through the makefiles Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------------------- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Devil-linux-develop mailing list Dev...@li... https://lists.sourceforge.net/lists/listinfo/devil-linux-develop -- WARPTROSSE {The knowledge of a man belongs to all the humanity} |
|
From: Andrzej O. <an...@ma...> - 2010-01-06 02:02:57
|
Heiko Zuerker wrote: > a tiny bit: > > make mrproper unpack all > > Or > > make mrproper unpack prepare build install iso > > > > The flag files for scripts which were successfully executed, moved to > build/tmp/FLAGS/<phase>/<scriptname> > > This part is only needed if you’re playing with scripts. Hi, But not exactly yet? I have now (after make mrproper unpack all): > ... > make: Entering directory `/build' > prepare: prepare log: /data/build/tmp/LOGS/prepare/prepare > make: *** [prepare] Error 1 > make: Leaving directory `/build' > make: *** [prepare] Error 1 > root:/build# and there is no log! Regards Andrzej Odyniec |
|
From: Andrzej O. <an...@ma...> - 2010-01-06 02:38:03
|
Andrzej Odyniec wrote: > Heiko Zuerker wrote: > >>a tiny bit: >> >>make mrproper unpack all >> >>Or >> >>make mrproper unpack prepare build install iso >> >> >> >>The flag files for scripts which were successfully executed, moved to >>build/tmp/FLAGS/<phase>/<scriptname> >> >>This part is only needed if you’re playing with scripts. > > > Hi, > > But not exactly yet? I have now (after make mrproper unpack all): > >>... >>make: Entering directory `/build' >>prepare: prepare log: /data/build/tmp/LOGS/prepare/prepare >>make: *** [prepare] Error 1 >>make: Leaving directory `/build' >>make: *** [prepare] Error 1 >>root:/build# > > > and there is no log! "ln -s / /data" temporarily solves problem :) Dear Heiko, How now to insert into dependency own tested build script(s)? How insert it automatically after official one? patching Makefile.*? manually editing proper Makefile.* every time? Regards Andrzej Odyniec |
|
From: Bruce S. <bw...@re...> - 2010-01-06 03:30:17
|
>> But not exactly yet? I have now (after make mrproper unpack all): >> >>>... >>>make: Entering directory `/build' >>>prepare: prepare log: /data/build/tmp/LOGS/prepare/prepare >>>make: *** [prepare] Error 1 >>>make: Leaving directory `/build' >>>make: *** [prepare] Error 1 >>>root:/build# >> >> and there is no log! > > "ln -s / /data" temporarily solves problem :) I just started a fresh compile, latest cvs, new lfs, mrproper. I didn't make the above link, and it made it through prepare fine. Actually, I did "make all" instead. Maybe that's the difference? root:/data/build# make all mount: proc already mounted mount: none already mounted or /sys busy mount: according to mtab, none is already mounted on /sys make: Entering directory `/data/build' prepare: prepare log: /data/build/tmp/LOGS/prepare/prepare prepare: distcc log: /data/build/tmp/LOGS/prepare/distcc prepare: binutils log: /data/build/tmp/LOGS/prepare/binutils prepare: gcc-4 log: /data/build/tmp/LOGS/prepare/gcc-4 prepare: libtool log: /data/build/tmp/LOGS/prepare/libtool prepare: autoconf log: /data/build/tmp/LOGS/prepare/autoconf prepare: bison log: /data/build/tmp/LOGS/prepare/bison prepare: makedepend log: /data/build/tmp/LOGS/prepare/makedepend prepare: nasm log: /data/build/tmp/LOGS/prepare/nasm prepare: automake log: /data/build/tmp/LOGS/prepare/automake prepare: dev86 log: /data/build/tmp/LOGS/prepare/dev86 make: Leaving directory `/data/build' mount: proc already mounted mount: none already mounted or /sys busy mount: according to mtab, none is already mounted on /sys make: Entering directory `/data/build' build: prepare log: /data/build/tmp/LOGS/build/prepare build: glibc log: /data/build/tmp/LOGS/build/glibc > Dear Heiko, > > How now to insert into dependency own tested build script(s)? > How insert it automatically after official one? > > patching Makefile.*? > manually editing proper Makefile.* every time? Good questions. :-) - BS |
|
From: Heiko Z. <he...@zu...> - 2010-01-06 12:50:41
|
> -----Original Message----- > From: Bruce Smith [mailto:bw...@re...] > Sent: Tuesday, January 05, 2010 9:30 PM > To: dev...@li... > Subject: Re: [Devil-linux-develop] no more insserv in build system > > >> But not exactly yet? I have now (after make mrproper unpack all): > >> > >>>... > >>>make: Entering directory `/build' > >>>prepare: prepare log: > /data/build/tmp/LOGS/prepare/prepare > >>>make: *** [prepare] Error 1 > >>>make: Leaving directory `/build' > >>>make: *** [prepare] Error 1 > >>>root:/build# > >> > >> and there is no log! > > > > "ln -s / /data" temporarily solves problem :) > > I just started a fresh compile, latest cvs, new lfs, mrproper. > I didn't make the above link, and it made it through prepare fine. > Actually, I did "make all" instead. Maybe that's the difference? > > root:/data/build# make all mount: > proc already mounted > mount: none already mounted or /sys busy > mount: according to mtab, none is already mounted on /sys > make: Entering directory `/data/build' [.............] > build: prepare log: > /data/build/tmp/LOGS/build/prepare > build: glibc log: > /data/build/tmp/LOGS/build/glibc I accidentally had the path to DL_DIR hardcoded in Makefile.inc. I removed the line and now it should work even if the build directory is not /data/build. Update from CVS and you should be fine. Sorry for that > > Dear Heiko, > > > > How now to insert into dependency own tested build script(s)? > > How insert it automatically after official one? > > > > patching Makefile.*? > > manually editing proper Makefile.* every time? > > Good questions. :-) Yes correct, you need to change the Makefile.xxx You need to add it twice per file: First you need to add it to one of the GROUP_xx entries, then you need to add a line like this: conntrack-tools: | $(GROUP_17) The GOUP_17 in this case means that everything in GROUP_17 has to be build first, before it compiles the script. I wrote a script which basically create Makefiles from the insserv configuration. At some point I want to get away from that also and have every script list the dependencies in the Makefile. For example: conntrack-tools: | depencency1 dependency2 dependency3 This way the adding of new functionality would be easier. Heiko |
|
From: Andrzej O. <an...@ma...> - 2010-01-06 14:02:22
|
Heiko Zuerker wrote: >>Good questions. :-) > > Yes correct, you need to change the Makefile.xxx This is obvious. > You need to add it twice per file: > First you need to add it to one of the GROUP_xx entries, then you need to > add a line like this: > conntrack-tools: | $(GROUP_17) > > The GOUP_17 in this case means that everything in GROUP_17 has to be build > first, before it compiles the script. This is obvious for me after lecture of particular makefiles and after comparation of scriptc before and after Your changes. I think, moving dependencies from insserv to explicite declarations in Makefile'a is good idea. It gives stability and there is no wait for insserv every build, so it is faster. Theoretically we can decide to build particular package and all it dependencies but not more. But branch experimental builds are harder. Look. I try to compile Asterisk. It builds. I'm now testing it. But Asterisk needs some number of other packages, libraries and drivers, i.e. dahdi, OSP, freetds, doxygen, jack, libogg, libpri, libresample, libvorbis, lua, newt, portaudio, radiusclient-ng, slang, spandsp, speex, sqlite2 (damn), stunner, unixODBC, etc. So I wrote scripts for all it. I hope, my work will be inserted into official D-L. And for now before experimental build I'm copying my scripts into proper directories and all rest do insserv. Dependencies was in insserv headers in scripts. Now I need every time I'm doing experimental build, insert my package names into rules in Makefile's. Manually it is horrible, so I need to do it from script. And now I have headache, how to write script InsertInto(Phase,Group,Before,Package) If You have ready function like this, please for it. > I wrote a script which basically create Makefiles from the insserv > configuration. At some point I want to get away from that also and have > every script list the dependencies in the Makefile. > For example: > conntrack-tools: | depencency1 dependency2 dependency3 > This way the adding of new functionality would be easier. But internal logic of Your script probably not need function like InsertInto. You start from total set of scripts. I need only add some positions into dependency hierarchy. But maybe? Regards Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2010-01-06 14:20:15
|
Hey, > -----Original Message----- > From: Andrzej Odyniec [mailto:an...@ma...] > Sent: Wednesday, January 06, 2010 8:02 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] no more insserv in build system > > Heiko Zuerker wrote: > >>Good questions. :-) > > > > Yes correct, you need to change the Makefile.xxx > > This is obvious. > > > You need to add it twice per file: > > First you need to add it to one of the GROUP_xx entries, then you > need to > > add a line like this: > > conntrack-tools: | $(GROUP_17) > > > > The GOUP_17 in this case means that everything in GROUP_17 has to be > build > > first, before it compiles the script. > > This is obvious for me after lecture of particular makefiles and after > comparation of scriptc before and after Your changes. > > I think, moving dependencies from insserv to explicite declarations in > Makefile'a is good idea. It gives stability and there is no wait for > insserv > every build, so it is faster. Theoretically we can decide to build > particular > package and all it dependencies but not more. But branch experimental > builds > are harder. > > Look. I try to compile Asterisk. It builds. I'm now testing it. But > Asterisk > needs some number of other packages, libraries and drivers, i.e. dahdi, > OSP, > freetds, doxygen, jack, libogg, libpri, libresample, libvorbis, lua, > newt, > portaudio, radiusclient-ng, slang, spandsp, speex, sqlite2 (damn), > stunner, > unixODBC, etc. So I wrote scripts for all it. I hope, my work will be > inserted > into official D-L. > > And for now before experimental build I'm copying my scripts into > proper > directories and all rest do insserv. Dependencies was in insserv > headers in > scripts. > > Now I need every time I'm doing experimental build, insert my package > names > into rules in Makefile's. Manually it is horrible, so I need to do it > from script. > > And now I have headache, how to write script > InsertInto(Phase,Group,Before,Package) > > If You have ready function like this, please for it. > > > I wrote a script which basically create Makefiles from the insserv > > configuration. At some point I want to get away from that also and > have > > every script list the dependencies in the Makefile. > > For example: > > conntrack-tools: | depencency1 dependency2 dependency3 > > This way the adding of new functionality would be easier. > > But internal logic of Your script probably not need function like > InsertInto. > You start from total set of scripts. I need only add some positions > into > dependency hierarchy. But maybe? How about something like this: We add an additional include line to the Makefiles: Makefile.<phase>.custom -> Makefile.build.custom , Makefile.install.custom Then you can have your own custom Makefiles, which you just have to copy in there. You would only have to specify the dependencies within your own custom scripts: script1: | script2 script3 script2: | script5 Let me try adding that functionality to the Makefiles. Heiko |
|
From: Andrzej O. <an...@ma...> - 2010-01-06 14:39:17
|
Heiko Zuerker wrote: > How about something like this: > We add an additional include line to the Makefiles: > Makefile.<phase>.custom -> Makefile.build.custom , Makefile.install.custom > > Then you can have your own custom Makefiles, which you just have to copy in > there. > > You would only have to specify the dependencies within your own custom > scripts: > script1: | script2 script3 > script2: | script5 > > Let me try adding that functionality to the Makefiles. Heiko, As for me -- perfect. Theoretical question: What, if one of custom scripts will need do something earlier. i.e. experimental patch of kernel before kernel compilation? And other need compiled kernel. I'm probably caviling. Regards -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2010-01-06 14:59:10
|
> -----Original Message----- > From: Andrzej Odyniec [mailto:an...@ma...] > Sent: Wednesday, January 06, 2010 8:39 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] no more insserv in build system > > Heiko Zuerker wrote: > > How about something like this: > > We add an additional include line to the Makefiles: > > Makefile.<phase>.custom -> Makefile.build.custom , > Makefile.install.custom > > > > Then you can have your own custom Makefiles, which you just have to > copy in > > there. > > > > You would only have to specify the dependencies within your own > custom > > scripts: > > script1: | script2 script3 > > script2: | script5 > > > > Let me try adding that functionality to the Makefiles. > > Heiko, > > As for me -- perfect. > > Theoretical question: What, if one of custom scripts will need do > something > earlier. i.e. experimental patch of kernel before kernel compilation? > And > other need compiled kernel. > > I'm probably caviling. Good question. Right now this would required patching the main makefiles, not sure how we can do this better. Maybe we need to add some additional special groups, something like GROUP_CUSTOM_PRE_KERNEL. We won't need a post-kernel, since the custom scripts are at the end anyway, What other places would we have where we may need to insert stuff? Heiko |
|
From: Andrzej O. <an...@ma...> - 2010-01-15 14:34:50
|
Heiko Zuerker wrote: > Right now this would required patching the main makefiles, not sure how we > can do this better. > Maybe we need to add some additional special groups, something like > GROUP_CUSTOM_PRE_KERNEL. We won't need a post-kernel, since the custom > scripts are at the end anyway, > What other places would we have where we may need to insert stuff? Hi, There is another problem now. We must include Makefile.*.custom (via Makefile.inc ofcourse) for two tasks: 1. for define variables GROUP_CUSTOM and GROUP_CUSTOM_BEFORE_KERNEL 2. for define additional "custom" targets and dependences (1.) should be done before "all" target definition in main Makefile.* (2.) should be done AFTER "all" target definition in mail Makefile.* or first target definition in Makefile.*.custom becomes DEFAULT target and will build only it and its dependencies... not more There is rule, that first defined target is default target. We can: (a) define "all" target again on begin of Makefile.*.custom as is defined in Makefile.* (b) divide Makefile.*.custom into two parts (with variable definitions and with targets definitions) and include this second part after "all" target definition in Makefile.* (c) transfer explicite given target to second level make (i.e. via variable); this solution is possibility to explicite give particular target other than "all" in time of experimental build Regards -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2010-01-25 22:45:49
|
> -----Original Message----- > From: Andrzej Odyniec [mailto:an...@ma...] > Sent: Friday, January 15, 2010 8:35 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] no more insserv in build system > > Heiko Zuerker wrote: > > Right now this would required patching the main makefiles, not sure > how we > > can do this better. > > Maybe we need to add some additional special groups, something like > > GROUP_CUSTOM_PRE_KERNEL. We won't need a post-kernel, since the > custom > > scripts are at the end anyway, > > What other places would we have where we may need to insert stuff? > > Hi, > > There is another problem now. > > We must include Makefile.*.custom (via Makefile.inc ofcourse) for two > tasks: > 1. for define variables GROUP_CUSTOM and GROUP_CUSTOM_BEFORE_KERNEL > 2. for define additional "custom" targets and dependences > > (1.) should be done before "all" target definition in main Makefile.* > (2.) should be done AFTER "all" target definition in mail Makefile.* or > first > target definition in Makefile.*.custom becomes DEFAULT target and will > build > only it and its dependencies... not more > > There is rule, that first defined target is default target. > > We can: > (a) define "all" target again on begin of Makefile.*.custom as is > defined in > Makefile.* > (b) divide Makefile.*.custom into two parts (with variable definitions > and > with targets definitions) and include this second part after "all" > target > definition in Makefile.* > (c) transfer explicite given target to second level make (i.e. via > variable); > this solution is possibility to explicite give particular target other > than > "all" in time of experimental build Sorry for the late response, I was out on vacation. I don't think I understand your request, could you please try to explain? Heiko |
|
From: Andrzej O. <an...@ma...> - 2010-01-26 11:43:48
|
Hi, Heiko Zuerker wrote: > I don't think I understand your request, could you please try to explain? I see, idea with including Makefile.*.custom as for now is unusable. In main Makefile.* is: > PHASE := build > include Makefile.inc > > GROUP_nn := aa bb ... ... > > all : $(GROUP_mm) $(GROUP_nn) ... $(GROUP_CUSTOM_BEFORE_KERNEL) $(GROUP_CUSTOM) > > ... > > # other place for include second level Makefile > > aa: | $(GROUP_mm) > > bb: | $(GROUP_nn) Makefile.inc includes Makefile.*.custom, where I should have: > GROUP_CUSTOM := my_aa my_bb > > GROUP_CUSTOM_BEFORE_KERNEL := > > my_bb: | my_aa > ... but after declaring target "my_bb" as above, my_bb becomes DEFAULT target of make instead of "all" target in main Makefile.* because first declared target becomes default. After this "make build" from chrooted /build directory makes not "all" target but only "my_bb" target and it's dependences. Changing point of include (i.e. after "all" target declaration in main Makefile.*) will give incomplete target "all" as result, because GROUP_CUSTOM variables before include are not defined yet. I suggested three solutions: First: repeating "all" target declaration in Makefile.*.custom as is in main makefile but before first custom target (this is not elegant). Second solution is split Makefile.*.custom into two parts, first including on begining and second just after "all" target. Third solution is calling in build.sh not "make" but explicite "make all" or maybe better "make $CUSTOM_TARGET" and setting this variable in main (first level) Makefile. Using this solution it is possible to build not always all scripts but only one, selected $CUSTOM_TARGET -- this can be sometime usable. I use fourth method: patching main Makefiles via inserting additional grups and targets by scripts. In actual form Makefile.*.custom is hard to use. Best regards -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2010-01-31 17:01:27
|
I set the default goal for the makefiles to 'all', which should solve the main problem for now. I'll look at your other idea when I get a chance. Heiko > -----Original Message----- > From: Andrzej Odyniec [mailto:an...@ma...] > Sent: Tuesday, January 26, 2010 5:43 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] no more insserv in build system > > Hi, > > Heiko Zuerker wrote: > > I don't think I understand your request, could you please try to > explain? > > I see, idea with including Makefile.*.custom as for now is unusable. > > In main Makefile.* is: > > > PHASE := build > > include Makefile.inc > > > > GROUP_nn := aa bb ... ... > > > > all : $(GROUP_mm) $(GROUP_nn) ... $(GROUP_CUSTOM_BEFORE_KERNEL) > $(GROUP_CUSTOM) > > > > ... > > > > # other place for include second level Makefile > > > > aa: | $(GROUP_mm) > > > > bb: | $(GROUP_nn) > > Makefile.inc includes Makefile.*.custom, where I should have: > > > GROUP_CUSTOM := my_aa my_bb > > > > GROUP_CUSTOM_BEFORE_KERNEL := > > > > my_bb: | my_aa > > ... > > but after declaring target "my_bb" as above, my_bb becomes DEFAULT > target of > make instead of "all" target in main Makefile.* because first declared > target > becomes default. > > After this "make build" from chrooted /build directory makes not "all" > target > but only "my_bb" target and it's dependences. > > Changing point of include (i.e. after "all" target declaration in main > Makefile.*) will give incomplete target "all" as result, because > GROUP_CUSTOM > variables before include are not defined yet. > > I suggested three solutions: > > First: repeating "all" target declaration in Makefile.*.custom as is in > main > makefile but before first custom target (this is not elegant). > > Second solution is split Makefile.*.custom into two parts, first > including on > begining and second just after "all" target. > > Third solution is calling in build.sh not "make" but explicite "make > all" or > maybe better "make $CUSTOM_TARGET" and setting this variable in main > (first > level) Makefile. Using this solution it is possible to build not always > all > scripts but only one, selected $CUSTOM_TARGET -- this can be sometime > usable. > > I use fourth method: patching main Makefiles via inserting additional > grups > and targets by scripts. > > In actual form Makefile.*.custom is hard to use. > > Best regards > > -- > Andrzej Odyniec > > ----------------------------------------------------------------------- > ------- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term > contracts > Personal 24x7 support from experience hosting pros just a phone call > away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
|
From: Heiko Z. <he...@zu...> - 2010-01-06 14:43:51
|
> > -----Original Message-----
> > From: Andrzej Odyniec [mailto:an...@ma...]
> > Sent: Wednesday, January 06, 2010 8:02 AM
> > To: dev...@li...
> > Subject: Re: [Devil-linux-develop] no more insserv in build system
> >
> > Heiko Zuerker wrote:
> > >>Good questions. :-)
> > >
> > > Yes correct, you need to change the Makefile.xxx
> >
> > This is obvious.
> >
> > > You need to add it twice per file:
> > > First you need to add it to one of the GROUP_xx entries, then you
> > need to
> > > add a line like this:
> > > conntrack-tools: | $(GROUP_17)
> > >
> > > The GOUP_17 in this case means that everything in GROUP_17 has to
> be
> > build
> > > first, before it compiles the script.
> >
> > This is obvious for me after lecture of particular makefiles and
> after
> > comparation of scriptc before and after Your changes.
> >
> > I think, moving dependencies from insserv to explicite declarations
> in
> > Makefile'a is good idea. It gives stability and there is no wait for
> > insserv
> > every build, so it is faster. Theoretically we can decide to build
> > particular
> > package and all it dependencies but not more. But branch experimental
> > builds
> > are harder.
> >
> > Look. I try to compile Asterisk. It builds. I'm now testing it. But
> > Asterisk
> > needs some number of other packages, libraries and drivers, i.e.
> dahdi,
> > OSP,
> > freetds, doxygen, jack, libogg, libpri, libresample, libvorbis, lua,
> > newt,
> > portaudio, radiusclient-ng, slang, spandsp, speex, sqlite2 (damn),
> > stunner,
> > unixODBC, etc. So I wrote scripts for all it. I hope, my work will be
> > inserted
> > into official D-L.
> >
> > And for now before experimental build I'm copying my scripts into
> > proper
> > directories and all rest do insserv. Dependencies was in insserv
> > headers in
> > scripts.
> >
> > Now I need every time I'm doing experimental build, insert my package
> > names
> > into rules in Makefile's. Manually it is horrible, so I need to do it
> > from script.
> >
> > And now I have headache, how to write script
> > InsertInto(Phase,Group,Before,Package)
> >
> > If You have ready function like this, please for it.
> >
> > > I wrote a script which basically create Makefiles from the insserv
> > > configuration. At some point I want to get away from that also and
> > have
> > > every script list the dependencies in the Makefile.
> > > For example:
> > > conntrack-tools: | depencency1 dependency2 dependency3
> > > This way the adding of new functionality would be easier.
> >
> > But internal logic of Your script probably not need function like
> > InsertInto.
> > You start from total set of scripts. I need only add some positions
> > into
> > dependency hierarchy. But maybe?
>
> How about something like this:
> We add an additional include line to the Makefiles:
> Makefile.<phase>.custom -> Makefile.build.custom ,
> Makefile.install.custom
>
> Then you can have your own custom Makefiles, which you just have to
> copy in
> there.
>
> You would only have to specify the dependencies within your own custom
> scripts:
> script1: | script2 script3
> script2: | script5
>
> Let me try adding that functionality to the Makefiles.
I added the change to CVS, update your sources and see how it works for you.
Here's the entry from the CHANGES file:
- added additional Makefiles for custom scripts which are not part of DL
- simply create your own Makefile.<phase>.custom and overwrite the CVS
version
to include your own additions to DL
Heiko
|
|
From: Dominic R. <dl...@ed...> - 2010-01-06 15:30:27
|
Andrzej Odyniec wrote: > > Look. I try to compile Asterisk. It builds. I'm now testing it... > I hope, my work will be inserted into official D-L. > You have my vote (FWIW) for Asterisk in official DL, if you can get it working. (Also rdiff-backup, librsync 0.9.7-5, ImageMagick suite - but I digress...) Dominic |
|
From: Heiko Z. <he...@zu...> - 2010-01-06 15:35:34
|
> -----Original Message----- > From: Dominic Raferd [mailto:dl...@ed...] > Sent: Wednesday, January 06, 2010 8:51 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] no more insserv in build system > > Andrzej Odyniec wrote: > > > > > Look. I try to compile Asterisk. It builds. I'm now testing it... > > I hope, my work will be inserted into official D-L. > > > > You have my vote (FWIW) for Asterisk in official DL, if you can get it > working. > > (Also rdiff-backup, librsync 0.9.7-5, ImageMagick suite - but I > digress...) We got imagemagick already ;-) I think you already got a feature request for the rdiff-backup in mantis. ;-) Heiko |
|
From: Dominic R. <dl...@ed...> - 2010-01-06 16:13:55
|
Heiko Zuerker wrote: >> -----Original Message----- >> From: Dominic Raferd [mailto:dl...@ed...] >> >> You have my vote (FWIW) for Asterisk in official DL, if you can get it >> working. >> >> (Also rdiff-backup, librsync 0.9.7-5, ImageMagick suite - but I >> digress...) > > We got imagemagick already ;-) > > I think you already got a feature request for the rdiff-backup in mantis. > ;-) > > Heiko > Oh, that's cool about imagemagick, sorry for my confusion. Yes I know my feature request for rdiff-backup is still there ;-) Off topic, but does DL support ext4? I use reiserfs without problems, but it does seem to be end-of-life. BTW, I love nano 2.2 in 1.4RC2 (sorry Bruce) Dominic |
|
From: Andrzej O. <an...@ma...> - 2010-01-06 13:20:28
|
Hi, Bruce Smith comment me: >>>But not exactly yet? I have now (after make mrproper unpack all): >>> >>> >>>>... >>>>make: Entering directory `/build' >>>>prepare: prepare log: /data/build/tmp/LOGS/prepare/prepare >>>>make: *** [prepare] Error 1 >>>>make: Leaving directory `/build' >>>>make: *** [prepare] Error 1 >>>>root:/build# >>> >>>and there is no log! >> >>"ln -s / /data" temporarily solves problem :) > > > I just started a fresh compile, latest cvs, new lfs, mrproper. > I didn't make the above link, and it made it through prepare fine. > Actually, I did "make all" instead. Maybe that's the difference? > > root:/data/build# make all mount: > proc already mounted > mount: none already mounted or /sys busy > mount: according to mtab, none is already mounted on /sys > make: Entering directory `/data/build' Bruce, Why You start from directory /data/build ?? According to documentation (http://www.devil-linux.org/documentation/1.3.x/ch03s01.html), I start unpacking lfssystem from ftp://ftp.devil-linux.org/pub/devel/sources/lfssystem-for-DL-1.3.4_and_up/lfssystem-SVN-20070314-cleaned.tar.bz2 In this environment is empty data directory. Next following documentation I go to lfssystem directory and I get script source from cvs with commands: > cvs -d:pserver:ano...@de...:/cvsroot/devil-linux login > cvs -z3 -d:pserver:ano...@de...:/cvsroot/devil-linux co build This all is unpacking into directory build/, not data/build and not data/ So according to instruction I'm going to build/, copy sources of packages from side and do update_src. i.e. last time I had only following downloads: > UPDATING from Devil-Linux FTP-Server Luxembourg-Kirchberg > Transferring file `busybox-1.15.3.tar.bz2' > Transferring file `dhcp-4.1.1rc1.tar.gz' > Transferring file `dhcpcd-5.1.4.tar.bz2' > Transferring file `dovecot-1.2.9.tar.gz' > Transferring file `gzip-1.3.13.tar.gz' > Transferring file `ncurses-5.7.tar.gz' > Transferring file `wvdial-1.61.tar.gz' > Transferring file `wvstreams-4.6.1.tar.gz' Now I do chroot > 'chroot /usr/src/lfssystem /usr/bin/env -i HOME=/root TERM=$TERM /bin/bash -login' login shell in new environment executes /root/.bash_profile and there is command > cd /data/build but always not executing, because there is no directory /data/build So I'm always following instruction from http://www.devil-linux.org/documentation/1.3.x/ch03s02.html and I'm going to directory build/ From this directory without linking /data to / there is no possibility to correct build with new scripts. Maybe You or Heiko are using other lfssystem? Bruce, Heiko. Please, check method I use and correct me Regards Andrzej Odyniec |
|
From: Bruce S. <bw...@re...> - 2010-01-06 14:31:29
|
> You need to add it twice per file: > First you need to add it to one of the GROUP_xx entries, then you need to > add a line like this: > conntrack-tools: | $(GROUP_17) > > The GOUP_17 in this case means that everything in GROUP_17 has to be build > first, before it compiles the script. > > I wrote a script which basically create Makefiles from the insserv > configuration. At some point I want to get away from that also and have > every script list the dependencies in the Makefile. > For example: > conntrack-tools: | depencency1 dependency2 dependency3 > This way the adding of new functionality would be easier. In the build/install scripts, are any of these lines needed now? ### BEGIN INIT INFO # Provides: unzip # Required-Start: $libs # Required-Stop: # Default-Start: 1 2 # Default-Stop: # Description: description ### END INIT INFO - BS |
|
From: Bruce S. <bw...@re...> - 2010-01-06 14:37:46
|
>> In the build/install scripts, are any of these lines needed now? >> >> ### BEGIN INIT INFO >> # Provides: unzip >> # Required-Start: $libs >> # Required-Stop: >> # Default-Start: 1 2 >> # Default-Stop: >> # Description: description >> ### END INIT INFO > > No. > I created a 'feature request' for cleaning that stuff up in the build > system. > If you feel like it, you can get started. ;-) Sure, I'll delete the stuff from all the scripts. - BS |
|
From: Bruce S. <bw...@re...> - 2010-01-06 15:31:15
|
>> Sure, I'll delete the stuff from all the scripts. > > I don't care what others say about you Bruce, but I think your okay! *LOL* > > Thanks for doing that. All done. (it's easy with vim, you should learn it!) :-) What about: build/scripts/cfg_runlevel ? Should that script be removed? - BS |
|
From: Heiko Z. <he...@zu...> - 2010-01-06 15:34:36
|
> -----Original Message----- > From: Bruce Smith [mailto:bw...@re...] > Sent: Wednesday, January 06, 2010 9:31 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] no more insserv in build system > > >> Sure, I'll delete the stuff from all the scripts. > > > > I don't care what others say about you Bruce, but I think your okay! > *LOL* > > > > Thanks for doing that. > > All done. (it's easy with vim, you should learn it!) :-) > > What about: build/scripts/cfg_runlevel ? > Should that script be removed? No that's for the init system of DL, we need that. I think we got everything now. Heiko |
|
From: Heiko Z. <he...@zu...> - 2010-01-06 14:36:10
|
> -----Original Message----- > From: Bruce Smith [mailto:bw...@re...] > Sent: Wednesday, January 06, 2010 8:31 AM > To: dev...@li... > Subject: Re: [Devil-linux-develop] no more insserv in build system > > > You need to add it twice per file: > > First you need to add it to one of the GROUP_xx entries, then you > need to > > add a line like this: > > conntrack-tools: | $(GROUP_17) > > > > The GOUP_17 in this case means that everything in GROUP_17 has to be > build > > first, before it compiles the script. > > > > I wrote a script which basically create Makefiles from the insserv > > configuration. At some point I want to get away from that also and > have > > every script list the dependencies in the Makefile. > > For example: > > conntrack-tools: | depencency1 dependency2 dependency3 > > This way the adding of new functionality would be easier. > > In the build/install scripts, are any of these lines needed now? > > ### BEGIN INIT INFO > # Provides: unzip > # Required-Start: $libs > # Required-Stop: > # Default-Start: 1 2 > # Default-Stop: > # Description: description > ### END INIT INFO No. I created a 'feature request' for cleaning that stuff up in the build system. If you feel like it, you can get started. ;-) Heiko |
