Re: LSB-si: ncurses with gcc 3.1
>
> I'll have to take a more serious look at how you guys are presently
> creating the SI and what the exact requirements are. From what little I
> have seen however, some of the recent additions in CVS, the way we now
> build, may be quite helpfull.
>
> Anyways.. I have some ideas, however I think I should get myself a
> little more imformed first :)
>
I especially like the way we multi stage build. This really helps cut down the
edit,compile,debug cycle.
Something we are discussing currently is how to deal with conditions. There is
a desire for one set of xml to work on all of the architectures. This means
optional packages, architecture names being used as variables (entities), etc.
We are currently using nalfs because we had the most success with it. There
has been some discussion on hardening it against a build failing so we can
restart builds. Gerard mentioned to me that the LFS group was redesigning
their automated tools.
Another issue with the XML is the use of <exec> in the code. I have found this
to hide problems and also to break restarting of busted builds. This has lead
us to talk about adding some new tags and reserving exec for only a few items
and future use.
To futher delineate LSB SI from the LFS xml files I am in the process of
renaming the entities and cleaning up comments. Just wanted to say this in
public so no one misconstrued this as hiding the origins. It would be in cvs
already but I took a trip last week.
Please, comment on changes we have made or improvements you have made in your
own branch. I have thick skin (-:
--
To UNSUBSCRIBE, email to lsb-impl-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
Reply to: