[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclinux-dev
Subject:    [uClinux-dev] Re: build philosophy
From:       Greg Ungerer <gerg () snapgear ! com>
Date:       2008-09-28 14:12:36
Message-ID: 48DF90D4.6010907 () snapgear ! com
[Download RAW message or body]


Hi Robin,

Robin Getz wrote:
> I'm just wondering - what is the expectation/common use...
> 
> When I'm building up images, I use "make image" all the time. It's fast, and 
> great when I'm just making some minor changes in the romfs/ directory. When 
> I'm testing things out, I just edit scripts (like /etc/rc) in the romfs/ 
> directory directly, and then just "make image". Works like a charm.

Yep, I often do that to. For quick and dirty testing.


> However, a problem occurs if I need to do a 'make' in the dist (to rebuild 
> some missing app), since my vendors/*/*/Makefile includes a:
> 
> $(ROMFSINST) /etc/rc
> 
> (like 150 other Makefiles) and romfs-inst.sh clobbers overtop of my local 
> changes in romfs/etc/rc with the one from vendors/*/*/rc
> 
> I could just stop making changes in the romfs/ directory (and do everything 
> in ./vendors/*/* - which I don't do today - since I don't want to check 
> anything into cvs/svn by mistake - and builds would take longer), or I could 
> add a new flag to romfs-inst.sh (which would not copy the file if it already 
> existed) - which would cause problems for people who expect today's 
> behaviour....
> 
> 
> Is ./romfs suppost to be the output of everything? (and people shouldn't be 
> editing things there?)

Well, yes. The "make romfs" step is supposed to construct a "final"
filesystem layout that is exactly what will end up in the target root
filesystem. The "make image" step is supposed to be the step that
rolls everything together into a form to load into the target.
In practice though sometimes romfs modifcation steps are done in
the "image" phase - somethimes it is very difficult to avoid.

If I am manually modifying the romfs/etc/rc for example I generally
copy into and out of /tmp as well - so I can put it back for debug
testing (and not lose it).

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a Secure Computing Company      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic