Re: Building RPM's (was: Re: [e-users] can't get embryo_cc to work)
On Wed, 28 Jul 2004 00:11:59 -0400 Michael Jennings <[EMAIL PROTECTED]> babbled:
(B
(B> On Wednesday, 28 July 2004, at 02:20:32 (+0300),
(B> Oded Arbel wrote:
(B>
(B> > I think most reasonable persons would agree that learning to rebuild
(B> > SRPMs is easeir then learning to checkout from CVS.
(B>
(B> It was far easier for me to learn how to run "cvs login" and "cvs
(B> checkout foo" than it was for me to figure out how to redirect rpm
(B> from /usr/src/redhat to my home directory, which directories to create
(B> under _topdir, how to invoke rpm in build mode with a spec file, where
(B> to put all the sources and patches ("so wait...patches are not sources
(B> in the spec file, but they go in the SOURCES directory? WTF??"),
(B> etc. Others may have different experiences.
(B
(Bi think he meant - you have a file.tar.gz (with a .spec file in it) or a
(B.src.rpm - building bianry rpms' from that is childs play - if you are willing
(Bto do it as root :). it's a 2-liner for e stuff
(B
(Bcd ecore
(Bmake dist
(Bsudo rpm -ta ecore-1.0.0_pre7.tar.gz
(B
(B:) i'm not so anal about building as a user :)
(B
(B> > I'm not talking about copy and paste, but about understanding what
(B> > is going on.
(B>
(B> Understanding what is going on when you rebuild an SRPM is more
(B> complex, IMHO. CVS is just tossing a bunch of files out in a
(B
(Bit is - doing it right (buildroots, install roots) is a lot of keep track of -
(Band when things go wrong... uh oh :) assuming its all honkey dory - its easy tho
(B:)
(B
(B> directory tree. SRPM's have several sections (%prep, %check, %files,
(B> %triggerpostun, ...), lots of macros and directives, and so on. Sure,
(B> learning to run "rpmbuild -ba file.spec" is fairly easy, but there's a
(B> lot more to it than that.
(B>
(B> > Ok. can you do that then, please ?
(B>
(B> I plan to; I just haven't had time. I'm working on getting caos-2
(B> ready for LWCE next week. Maybe if I have time while I'm there...
(B>
(B> > That would be useful. thanks for the suggestion. I noticed that
(B> > several spec files do not have the BuildSuggests entry at all or it
(B> > does not contain the entries that I think it should have. if I test
(B> > and report on discrepancies between whats written and what is
(B> > actually required, will you take a look at adding more information
(B> > to the BuildSuggests entry ?
(B>
(B> Absolutely. The beauty of BuildSuggests: is that they're non-fatal,
(B> so even if my distro doesn't have a particular package, I can still
(B> add it as a BuildSuggests: for anyone else whose distro might need
(B> it. :)
(B>
(B> > Not if I do an export. in any case - I always assumed that the
(B> > tarball/source RPM is a clean snapshot of the source, a.k.a. CVS
(B> > snapshot/branch.
(B>
(B> Negative. Files like "configure" and "config.h.in" and "Makefile.in"
(B> are NOT in CVS because, like CVS, the autoFUCK tools are developer
(B> tools. If these files are put into revision control, every time a
(B> different developer runs autogen.sh, even without making source code
(B> changes, those files change. And revision control on those files is
(B> worthless because they're auto-generated.
(B>
(B> The tarball created by "make dist" and "make distcheck" contains
(B> exactly what the developer(s) have said should be there; nothing more,
(B> nothing less. The end user (or the spec file) should not need libtool
(B> and automake and such installed; they have only to run ./configure and
(B> make install. But tarring up a clean cvs export will not include
(B> these files, and it may include files it shouldn't. "make dist" is
(B> the best way. After all, it's what the developers themselves do. :)
(B>
(B> > I dont understand why, but I'm willing to accept it. I'm currently
(B> > handling that in the script I'm writing.
(B>
(B> I assume you're familiar with the -n option to the %setup macro. The
(B> default directory name is %{name}-%{version} because that's how the
(B> vast majority of packages are done. It's packages that don't follow
(B> the de facto standard that cause spec files to have to throw that -n
(B> in there.
(B>
(B> > If I understand correctly. maintainer-mode is evil (or so it is
(B> > written). but I see your point. thanks.
(B>
(B> I'm not sure where you read/heard that, but it's utter nonsense.
(B> Maintainer mode (or "make maintainer-clean" in particular) comes in
(B> very handy for developers. It cleans up auto-generated files which
(B> should not be under revision control but should be in a dist tarball
(B> (i.e., files which "make distclean" does not remove).
(B>
(B> > Not standard. more of "trying not to break things which other people
(B> > did" :-)
(B>
(B> That's exactly what I'm trying to do. I'm sure everyone is familiar
(B> with the apache-2.x.x vs. apache2-2.x.x issue, along with glib/glib2
(B> and several others. Until BuildRequires: gains
Re: [e-users] can't get embryo_cc to work
Can you send a DIRECT link the image? I can't find it.. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Wed, 2004-07-28 at 01:23, Michael Jennings wrote: > You're arguing that SRPM's are better because they 1 step instead of > 3. That's splitting the hair mighty thin. Anyone who knows how to > invoke rpmbuild --rebuild knows it because someone told them. Thus, > that person is equally able to cut and paste the command I gave. I think most reasonable persons would agree that learning to rebuild SRPMs is easeir then learning to checkout from CVS. I'm not talking about copy and paste, but about understanding what is going on. simply a more limited skillset is required. but your argument is valid and I guess its personal perspective and I will say nothing more :-) > Nobody's slinging mud. In my experience, Mandrake is too > bleeding-edge for their own good. If it works for you, fine, but you > have to acknowledge that problems may be caused by your toolset/distro > choice. The same as /you/ have to acknowledge that my problems may be caused by your toolset ;-) > Nope. I thought I already explained this. Instead, requiring > /usr/include/gif_lib.h and /usr/lib/libgif.so accomplishes the same > thing (given a good dep solver) without being distro-specific. Ok. can you do that then, please ? > If you refuse to use Mezzanine, you can always add something like this > to your script before calling rpmbuild: > > perl -pi.bak -e 's/\#BuildSuggests/BuildRequires/g' *.spec That would be useful. thanks for the suggestion. I noticed that several spec files do not have the BuildSuggests entry at all or it does not contain the entries that I think it should have. if I test and report on discrepancies between whats written and what is actually required, will you take a look at adding more information to the BuildSuggests entry ? > > I thought that I can make a dist ball just by running the > > auto-tools, and packaging the CVS directory after that. can you > > please explain what's wrong with this approach? > > CVS directories and other junk end up in the tarball. Not if I do an export. in any case - I always assumed that the tarball/source RPM is a clean snapshot of the source, a.k.a. CVS snapshot/branch. > Also the > tarball's top-level path does not include the version number, which is > a big no-no in most cases. I dont understand why, but I'm willing to accept it. I'm currently handling that in the script I'm writing. > > I think that packaging > > the CVS dir as it comes out of the CVS and building off that is the > > ultimate goal and I sometimes do that. > > That would be unfortunate. You're better off invoking autogen like > this: > > make maintainer-clean > ./autogen.sh --enable-maintainer-mode > make dist If I understand correctly. maintainer-mode is evil (or so it is written). but I see your point. thanks. > I am in frequent contact with Jeff Johnson (RPM lead developer) and > have yet to hear of any such standard, but perhaps I just missed it. Not standard. more of "trying not to break things which other people did" :-) > Since you seem rather opposed to any build tools other than what > you're already used to, Actually - what everyone has. if you want to have your software to built out of CVS, then you need to accept that most people will have only the standard tools that came with their distro (and then only those that sits nicely under the label "you need this to develop and build software". if you think that everyone that builds out of CVS should have Mezzanine, then please note so in some sort of documentation (and I don't consider the mail archives of the user list to be "documentation"). Thanks for all the info. I'll take a look at what you've wrote and either integrate this somehow into my system or follow your advice and just use Mezzanine. I can certainly say that I've learned quite a few new things in this thread :-) -- Oded ::.. "Many people lose their tempers merely from seeing you keep yours." -- Frank Moore Colby --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On 28/07/04, at 09:29 +0100, Andrew Elcock <[EMAIL PROTECTED]> wrote: > Didier Casse wrote: > > > >>>and they do work! > >> > >>As do mine. The fact that I've built them all and imported the SRPM's > >>into caos CVS (address in previous e-mail) tends to prove that fact > >>rather well. > > > > > > Certain modules do not have specs. Where's elicit/engage specs for > > instance? > > > > enage has not been packaged for any distro yet, it has not been deemed > ready, and so is missing some dist functionality. > I created a spec for it. Build rpm out of it and it works fine. :-) I understand that most of these stuff are not ready but we can still enjoy them. Engage is cool! Thanks for the nice work. With kind regards, Didier. --- PhD student. Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: didierbe at sps dot nus dot edu dot sg Web: http://ssls.nus.edu.sg --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
Didier Casse wrote: and they do work! As do mine. The fact that I've built them all and imported the SRPM's into caos CVS (address in previous e-mail) tends to prove that fact rather well. Certain modules do not have specs. Where's elicit/engage specs for instance? enage has not been packaged for any distro yet, it has not been deemed ready, and so is missing some dist functionality. smime.p7s Description: S/MIME Cryptographic Signature
Building RPM's (was: Re: [e-users] can't get embryo_cc to work)
On Wednesday, 28 July 2004, at 02:20:32 (+0300),
Oded Arbel wrote:
> I think most reasonable persons would agree that learning to rebuild
> SRPMs is easeir then learning to checkout from CVS.
It was far easier for me to learn how to run "cvs login" and "cvs
checkout foo" than it was for me to figure out how to redirect rpm
from /usr/src/redhat to my home directory, which directories to create
under _topdir, how to invoke rpm in build mode with a spec file, where
to put all the sources and patches ("so wait...patches are not sources
in the spec file, but they go in the SOURCES directory? WTF??"),
etc. Others may have different experiences.
> I'm not talking about copy and paste, but about understanding what
> is going on.
Understanding what is going on when you rebuild an SRPM is more
complex, IMHO. CVS is just tossing a bunch of files out in a
directory tree. SRPM's have several sections (%prep, %check, %files,
%triggerpostun, ...), lots of macros and directives, and so on. Sure,
learning to run "rpmbuild -ba file.spec" is fairly easy, but there's a
lot more to it than that.
> Ok. can you do that then, please ?
I plan to; I just haven't had time. I'm working on getting caos-2
ready for LWCE next week. Maybe if I have time while I'm there...
> That would be useful. thanks for the suggestion. I noticed that
> several spec files do not have the BuildSuggests entry at all or it
> does not contain the entries that I think it should have. if I test
> and report on discrepancies between whats written and what is
> actually required, will you take a look at adding more information
> to the BuildSuggests entry ?
Absolutely. The beauty of BuildSuggests: is that they're non-fatal,
so even if my distro doesn't have a particular package, I can still
add it as a BuildSuggests: for anyone else whose distro might need
it. :)
> Not if I do an export. in any case - I always assumed that the
> tarball/source RPM is a clean snapshot of the source, a.k.a. CVS
> snapshot/branch.
Negative. Files like "configure" and "config.h.in" and "Makefile.in"
are NOT in CVS because, like CVS, the autoFUCK tools are developer
tools. If these files are put into revision control, every time a
different developer runs autogen.sh, even without making source code
changes, those files change. And revision control on those files is
worthless because they're auto-generated.
The tarball created by "make dist" and "make distcheck" contains
exactly what the developer(s) have said should be there; nothing more,
nothing less. The end user (or the spec file) should not need libtool
and automake and such installed; they have only to run ./configure and
make install. But tarring up a clean cvs export will not include
these files, and it may include files it shouldn't. "make dist" is
the best way. After all, it's what the developers themselves do. :)
> I dont understand why, but I'm willing to accept it. I'm currently
> handling that in the script I'm writing.
I assume you're familiar with the -n option to the %setup macro. The
default directory name is %{name}-%{version} because that's how the
vast majority of packages are done. It's packages that don't follow
the de facto standard that cause spec files to have to throw that -n
in there.
> If I understand correctly. maintainer-mode is evil (or so it is
> written). but I see your point. thanks.
I'm not sure where you read/heard that, but it's utter nonsense.
Maintainer mode (or "make maintainer-clean" in particular) comes in
very handy for developers. It cleans up auto-generated files which
should not be under revision control but should be in a dist tarball
(i.e., files which "make distclean" does not remove).
> Not standard. more of "trying not to break things which other people
> did" :-)
That's exactly what I'm trying to do. I'm sure everyone is familiar
with the apache-2.x.x vs. apache2-2.x.x issue, along with glib/glib2
and several others. Until BuildRequires: gains the ability to handle
the || (OR) operator, non-fatal buildreq's are (IMHO) the cleanest way
to tackle this issue.
> Actually - what everyone has. if you want to have your software to
> built out of CVS, then you need to accept that most people will have
> only the standard tools that came with their distro (and then only
> those that sits nicely under the label "you need this to develop and
> build software".
As I said before, Mezz isn't a requirement. It doesn't do anything
that you can't do yourself. It just saves the person the trouble of
changing all those macro values, copying around source tarballs and
spec files, relocating built packages to the current directory, etc.
Mezz exists primarily because I got sick of doing the same shit over
and over by hand. :)
For example, ever needed to create a new patch for an existing SRPM?
You have to install it (which requires the aforementioned macros and
directory structure), untar the sources and apply all the patches,
make your changes, untar and patc
Re: [e-users] can't get embryo_cc to work
On Wednesday, 28 July 2004, at 10:18:37 (+0800), Didier Casse wrote: > Certain modules do not have specs. Where's elicit/engage specs for > instance? The apps don't all have them yet. I'm getting there. > Btw use "License" instead of "Copyright" :-) > > Excerp from > http://fedora.redhat.com/participate/developers-guide/ch-rpm-building.html: > > - > License > One of GPL, LGPL, BSD(-like), Artistic, etc. Most old packages > erroneously call this the "Copyright" field. This is incorrect but the two > are synonyms for each other. Fix old packages to have the correct tag if > found. > > - While I do not consider Fedora the deity of All Things RPM any more than I did RedHat, I will mention it to Jeff and see what he says. But calling something both "incorrect" and "a synonym" makes no sense; both cannot be true. If neither has been deprecated or obsoleted, and they're synonyms, both are equally valid. Besides, I've seen RedHat packages that use "Copyright:" too. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "A slipping gear could let your M203 grenade launcher fire when you least expect it. That would make you quite unpopular in what's left of your unit." -- In the August 1993 issue, page 9, of PS magazine --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On 27/07/04, at 11:45 -0400, Michael Jennings <[EMAIL PROTECTED]> wrote: > On Tuesday, 27 July 2004, at 17:52:35 (+0800), > Didier Casse wrote: > > > Interested in some nice and reliable spec files? > > You seem to be implying that the spec files in CVS are not nice and/or > reliable. If you have problems with them, let me know rather than > pointing people in the wrong direction. Not implying anything. You're the one making such deductions! I just asked if anybody's interested in mine that I made independently and according to the latest Fedora's guidelines for building rpms. If people want it fine, if they don't that's fine too. Well 11 people emailed me although they can find some specs in cvs. Don't take everything too personnally. > > > and they do work! > > As do mine. The fact that I've built them all and imported the SRPM's > into caos CVS (address in previous e-mail) tends to prove that fact > rather well. Certain modules do not have specs. Where's elicit/engage specs for instance? Btw use "License" instead of "Copyright" :-) Excerp from http://fedora.redhat.com/participate/developers-guide/ch-rpm-building.html: - License One of GPL, LGPL, BSD(-like), Artistic, etc. Most old packages erroneously call this the "Copyright" field. This is incorrect but the two are synonyms for each other. Fix old packages to have the correct tag if found. - With kind regards, Didier. --- PhD student. Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: didierbe at sps dot nus dot edu dot sg Web: http://ssls.nus.edu.sg --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Wed, 2004-07-28 at 01:23, Michael Jennings wrote: > You're arguing that SRPM's are better because they 1 step instead of > 3. That's splitting the hair mighty thin. Anyone who knows how to > invoke rpmbuild --rebuild knows it because someone told them. Thus, > that person is equally able to cut and paste the command I gave. I think most reasonable persons would agree that learning to rebuild SRPMs is easeir then learning to checkout from CVS. I'm not talking about copy and paste, but about understanding what is going on. simply a more limited skillset is required. but your argument is valid and I guess its personal perspective and I will say nothing more :-) > Nobody's slinging mud. In my experience, Mandrake is too > bleeding-edge for their own good. If it works for you, fine, but you > have to acknowledge that problems may be caused by your toolset/distro > choice. The same as /you/ have to acknowledge that my problems may be caused by your toolset ;-) > Nope. I thought I already explained this. Instead, requiring > /usr/include/gif_lib.h and /usr/lib/libgif.so accomplishes the same > thing (given a good dep solver) without being distro-specific. Ok. can you do that then, please ? > If you refuse to use Mezzanine, you can always add something like this > to your script before calling rpmbuild: > > perl -pi.bak -e 's/\#BuildSuggests/BuildRequires/g' *.spec That would be useful. thanks for the suggestion. I noticed that several spec files do not have the BuildSuggests entry at all or it does not contain the entries that I think it should have. if I test and report on discrepancies between whats written and what is actually required, will you take a look at adding more information to the BuildSuggests entry ? > > I thought that I can make a dist ball just by running the > > auto-tools, and packaging the CVS directory after that. can you > > please explain what's wrong with this approach? > > CVS directories and other junk end up in the tarball. Not if I do an export. in any case - I always assumed that the tarball/source RPM is a clean snapshot of the source, a.k.a. CVS snapshot/branch. > Also the > tarball's top-level path does not include the version number, which is > a big no-no in most cases. I dont understand why, but I'm willing to accept it. I'm currently handling that in the script I'm writing. > > I think that packaging > > the CVS dir as it comes out of the CVS and building off that is the > > ultimate goal and I sometimes do that. > > That would be unfortunate. You're better off invoking autogen like > this: > > make maintainer-clean > ./autogen.sh --enable-maintainer-mode > make dist If I understand correctly. maintainer-mode is evil (or so it is written). but I see your point. thanks. > I am in frequent contact with Jeff Johnson (RPM lead developer) and > have yet to hear of any such standard, but perhaps I just missed it. Not standard. more of "trying not to break things which other people did" :-) > Since you seem rather opposed to any build tools other than what > you're already used to, Actually - what everyone has. if you want to have your software to built out of CVS, then you need to accept that most people will have only the standard tools that came with their distro (and then only those that sits nicely under the label "you need this to develop and build software". if you think that everyone that builds out of CVS should have Mezzanine, then please note so in some sort of documentation (and I don't consider the mail archives of the user list to be "documentation"). Thanks for all the info. I'll take a look at what you've wrote and either integrate this somehow into my system or follow your advice and just use Mezzanine. I can certainly say that I've learned quite a few new things in this thread :-) -- Oded ::.. "Many people lose their tempers merely from seeing you keep yours." -- Frank Moore Colby --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Wednesday, 28 July 2004, at 00:51:08 (+0300),
Oded Arbel wrote:
> > rpmbuild -ba --define "_sourcedir $PWD" --define "_specdir $PWD" \
> > --define "_topdir $PWD" --define "%_srcrpmdir $PWD" \
> > --define "_rpmdir $PWD"
>
> That's mighty useful, I didn't know about that. I still think that
> SRPMS are more useful then CVS for building distribution packages as
> they are less steps involved. specificly there are people who don't
> know a thing about CVS but can manage a simple rebuild command.
You're arguing that SRPM's are better because they 1 step instead of
3. That's splitting the hair mighty thin. Anyone who knows how to
invoke rpmbuild --rebuild knows it because someone told them. Thus,
that person is equally able to cut and paste the command I gave.
> Please don't go mud-slinging. I've been using Mandrake for over 5
> years w/o major problems and in the last couple of years w/o any
> problem. I can say the same for almost any distro you choose
> (excluding of course RedHat 6.x and distro with the same outdated
> software, i.e. debian latest stable), but I won't.
Nobody's slinging mud. In my experience, Mandrake is too
bleeding-edge for their own good. If it works for you, fine, but you
have to acknowledge that problems may be caused by your toolset/distro
choice.
> Thanks - that did the trick. can you please add libungif-devel as
> BuildRequires for the imlib2 spec file ?
Nope. I thought I already explained this. imlib2 does NOT require
the libungif-devel package. It requires the GIF library and its
headers. This may or may not correspond to a package called
libungif-devel on any particular distro. Instead, requiring
/usr/include/gif_lib.h and /usr/lib/libgif.so accomplishes the same
thing (given a good dep solver) without being distro-specific.
> Thanks. is it possible that it be put in the e17 CVS like the rest
> of the spec files ?
I'll commit it shortly.
> I don't use Messaine and I don't use yum (I have used it several
> times, including as recent as FC2, and I still think urpmi is way
> better). see below.
Doesn't matter what you use. Mezzanine can handle anything that it
can pass package names to for installation, preferably in a non-fatal
way.
If you refuse to use Mezzanine, you can always add something like this
to your script before calling rpmbuild:
perl -pi.bak -e 's/\#BuildSuggests/BuildRequires/g' *.spec
> I thought that I can make a dist ball just by running the
> auto-tools, and packaging the CVS directory after that. can you
> please explain what's wrong with this approach?
CVS directories and other junk end up in the tarball. Also the
tarball's top-level path does not include the version number, which is
a big no-no in most cases. The "make dist" command is there for
precisely this reason.
> The problem I'm having (IMHO anyway - it may all be just in my mind)
> is that running configured/make and friends changes a lot of files
> in the CVS dir, and thus making the next build only as clean as make
> distclean can make it - which is as usall an error-prone process. I
> rather build stuff out of as clean as dist as possible, with the
> least ammounts of steps that can go wrong. I think that packaging
> the CVS dir as it comes out of the CVS and building off that is the
> ultimate goal and I sometimes do that.
That would be unfortunate. You're better off invoking autogen like
this:
make maintainer-clean
./autogen.sh --enable-maintainer-mode
make dist
> There are ways to add BuildRequires in a way that is not (or at
> least - as little as possible) distribution dependant.
Mine is one of them. If you know of others, by all means, speak up.
I am in frequent contact with Jeff Johnson (RPM lead developer) and
have yet to hear of any such standard, but perhaps I just missed it.
Since you seem rather opposed to any build tools other than what
you're already used to, I'll show you how Jeff proposed doing it.
First, you'll need to create a directory full of files. Each file's
name is the package name and its contents are the buildreq's for that
package. Then put the following macros in your ~/.rpmmacros (or other
macros) file:
%description \
# %{suseneeds} # %{mdkneeds} # %{rhelneeds} # %{caosneeds} \
%{expand:%%undefine description} \
%%description
%mdkneeds \
BuildRequires: /dev/null %(cat /path/to/hintfiles/%{name} 2>/dev/null) \
%{nil}
> I don't think its fair to assume that just because something was
> broken in the past it will always and forever be broken (see
> Mandrake comment above).
I don't assume that. But it is broken *now*, and I'm developing
*now*. If things change in the future, we'll change with them.
> Oh, come on. this is not fair. I can just as well say that my
> problem is you using non-standard tools in an undocumented way and
> expecting people to magically know that and use them
I don't. Mezzanine is not required. It just makes it easier. In
fact, that's why Mezzanine exists: it makes lots of
Re: [e-users] can't get embryo_cc to work
On Tue, 2004-07-27 at 18:43, Michael Jennings wrote: > On Tuesday, 27 July 2004, at 03:26:34 (+0300), > Oded Arbel wrote: > > > I really appriciate the effort of supplying valid spec files in the > > CVS - its make life so much easier for distributions and other > > packagers. I wish that more projects will follow. > > I'm not so sure I agree. Many software developers do not know how to > make correct spec files. I can't even begin to count the number of > projects I've run into where the spec file was out-of-date, incorrect, > or just plain nasty. I try very hard to make good, clean, portable > spec files, and I've been doing it since around 2000. > At worst we're no worse off then w/o spec files at all, and we can offer fixes. at best we have less work to do :-) > In fact, for the entirety of EFL (save perhaps > emotion), I can build RPM's by running the following in each > directory: > > ./autogen.sh && make dist && mzbuild > > The "mzbuild" command is part of Mezzanine (http://www.kainx.org/mezzanine/) > and makes lots of things about building and maintaining packages a > *lot* simpler. If you don't have mezz and don't want to use it, this > will do something quite similar to "mzbuild" in the above command: > > rpmbuild -ba --define "_sourcedir $PWD" --define "_specdir $PWD" \ > --define "_topdir $PWD" --define "%_srcrpmdir $PWD" \ > --define "_rpmdir $PWD" That's mighty useful, I didn't know about that. I still think that SRPMS are more useful then CVS for building distribution packages as they are less steps involved. specificly there are people who don't know a thing about CVS but can manage a simple rebuild command. > > - edje: autogen.sh does not work. > > It works quite well for me as of 3 days ago, so I'd be surprised if > it's not valid bash. More likely a problem with your distro. > Mandrake is notorious for instability. Please don't go mud-slinging. I've been using Mandrake for over 5 years w/o major problems and in the last couple of years w/o any problem. I can say the same for almost any distro you choose (excluding of course RedHat 6.x and distro with the same outdated software, i.e. debian latest stable), but I won't. It was a problem with my script. I'm sorry I didn't found it earlier. it modified autogen.sh and didn't do it correctly. sorry for bothering. > > - imlib2 does not build - it fails finding any files for the imlib-loader_gif > > sub-package. > > Probably because you don't have libungif-devel installed. Thanks - that did the trick. can you please add libungif-devel as BuildRequires for the imlib2 spec file ? > > - imlib2_loaders does not have a spec file - it has a spec.in file. is the > > spec file supposed to be generated by the configure scripts ? that's kind of > > useless as configure is supposed to be run from the spec file. > > This must've been an oversight on my part. The spec file I use can be > found via CVS at :pserver:[EMAIL PROTECTED]:/var/cvs in > caos/users/mej/imlib2_loaders/F/imlib2_loaders.spec Thanks. is it possible that it be put in the e17 CVS like the rest of the spec files ? > > - I failed to build etox, but I don't think its RPM specific. I'll investigate > > more and write about it later. > > Building RPM's from CVS still means that you need all the prereq's. > Although if you use Mezzanine and set your hint-installer variable to > "yum -ty install" it will auto-install all buildreq's for you. I don't use Messaine and I don't use yum (I have used it several times, including as recent as FC2, and I still think urpmi is way better). see below. > > - In all the libraries, autogen.sh by deafult runs configure (while the > > comment above it implies that it is commented out, which is not the case). > > autogen.sh is needed to generate the configure script and other such > tools. .. you can simply run "make dist" followed by > rpmbuild/mzbuild. I thought that I can make a dist ball just by running the auto-tools, and packaging the CVS directory after that. can you please explain what's wrong with this approach ? The problem I'm having (IMHO anyway - it may all be just in my mind) is that running configured/make and friends changes a lot of files in the CVS dir, and thus making the next build only as clean as make distclean can make it - which is as usall an error-prone process. I rather build stuff out of as clean as dist as possible, with the least ammounts of steps that can go wrong. I think that packaging the CVS dir as it comes out of the CVS and building off that is the ultimate goal and I sometimes do that. > The problem with BuildRequires is that they aren't distro-portable. > And because missing BuildRequires are fatal (rpmbuild will die without > them, even if they're not strictly needed), There are ways to add BuildRequires in a way that is not (or at least - as little as possible) distribution dependant. there are efforts to solve the last remaining cross distribution dependency problems. I don
Re: [e-users] can't get embryo_cc to work
On Tuesday, 27 July 2004, at 17:52:35 (+0800), Didier Casse wrote: > Interested in some nice and reliable spec files? You seem to be implying that the spec files in CVS are not nice and/or reliable. If you have problems with them, let me know rather than pointing people in the wrong direction. > and they do work! As do mine. The fact that I've built them all and imported the SRPM's into caos CVS (address in previous e-mail) tends to prove that fact rather well. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "USA Today has come out with a new survey: Apparently three out of four people make up 75 percent of the population." -- David Letterman --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Tuesday, 27 July 2004, at 03:26:34 (+0300), Oded Arbel wrote: > I really appriciate the effort of supplying valid spec files in the > CVS - its make life so much easier for distributions and other > packagers. I wish that more projects will follow. I'm not so sure I agree. Many software developers do not know how to make correct spec files. I can't even begin to count the number of projects I've run into where the spec file was out-of-date, incorrect, or just plain nasty. I try very hard to make good, clean, portable spec files, and I've been doing it since around 2000. > I'm trying to build RPMs from CVS for my system (Mandrake > 10). actually - I'm writing a script that will allow to build E17 > CVS and install it as RPMs directly. the resulting RPMs will of > course be useless for anyone not using Mandrake 10, but the source > RPMs generated will be useful to build the specific CVS snapshot on > other systems - much more so then checking out of CVS would ever be. Perhaps, perhaps not. As I said, building RPM's and SRPM's from CVS is very easy. In fact, for the entirety of EFL (save perhaps emotion), I can build RPM's by running the following in each directory: ./autogen.sh && make dist && mzbuild The "mzbuild" command is part of Mezzanine (http://www.kainx.org/mezzanine/) and makes lots of things about building and maintaining packages a *lot* simpler. If you don't have mezz and don't want to use it, this will do something quite similar to "mzbuild" in the above command: rpmbuild -ba --define "_sourcedir $PWD" --define "_specdir $PWD" \ --define "_topdir $PWD" --define "%_srcrpmdir $PWD" \ --define "_rpmdir $PWD" (These can all go on one line; I split the line for readability.) > Now - I'm having some problems with doing so, which makes me think > your last decleration may not be so true (especially the "easy" > part). specificly I'm currently stuck with these problems, and I do > hope someone can comment on how I can resolve this issues: > > - edje: autogen.sh does not work. the autogen.sh script looks nothing like the > scripts for the other libraries, and bash complains about all the curly > braces in the checks in the front. I can't tell what the problem as I'm not > familiar with this syntax - I don't even think its valid bash. The m4 > directory is also missing. It works quite well for me as of 3 days ago, so I'd be surprised if it's not valid bash. More likely a problem with your distro. Mandrake is notorious for instability. > - imlib2 does not build - it fails finding any files for the imlib-loader_gif > sub-package. Probably because you don't have libungif-devel installed. > - imlib2_loaders does not have a spec file - it has a spec.in file. is the > spec file supposed to be generated by the configure scripts ? that's kind of > useless as configure is supposed to be run from the spec file. This must've been an oversight on my part. The spec file I use can be found via CVS at :pserver:[EMAIL PROTECTED]:/var/cvs in caos/users/mej/imlib2_loaders/F/imlib2_loaders.spec > - I failed to build etox, but I don't think its RPM specific. I'll investigate > more and write about it later. Building RPM's from CVS still means that you need all the prereq's. Although if you use Mezzanine and set your hint-installer variable to "yum -ty install" it will auto-install all buildreq's for you. > - In all the libraries, autogen.sh by deafult runs configure (while the > comment above it implies that it is commented out, which is not the case). as > the order of building RPMs (AFAIU) is - autogen, rpmbuild (which runs > configure, make and make install), that step is redundant. I currently solve > this by automaticly "fixing" the autogen.sh script in my build process. autogen.sh is needed to generate the configure script and other such tools. If the configure script is already there, as it would be in a dist tarball, you don't need to run autogen.sh. Once you've run it in your directory, and assuming nobody makes any changes to Makefile.am's or other autoSPLAT files, you can simply run "make dist" followed by rpmbuild/mzbuild. > - All the spec files are missing BuildRequires tags that are needed > to force a build order - other wise users can try to build packages > out of order and fail. the BuildRequires tag is supposed to help > users by letting them know what they need before spending a lot of > times (sometimes a couple of hours) on a build that would fail. The problem with BuildRequires is that they aren't distro-portable. And because missing BuildRequires are fatal (rpmbuild will die without them, even if they're not strictly needed), I use #BuildSuggests instead, which mezzanine understands and uses but is not fatal to rpmbuild. I plan to add file-based dependencies which are more accurate and don't require distinction between, e.g., libungif-devel vs. libgif-devel vs. libungif vs. etc. I just haven't yet. > I haven't tried to compile all the libraries a
Re: [e-users] can't get embryo_cc to work
On Tue, 27 Jul 2004 09:58:21 +0900, Carsten Haitzler <[EMAIL PROTECTED]> wrote: On Mon, 26 Jul 2004 22:04:58 +0200 [EMAIL PROTECTED] babbled: Hello all, I downloaded yesterday most EFL libraries and some applications from CVS. The libraries compiled fine, but when I tried to compile Entice and Entrance I got the following error: fixed. snprintf changes broke embryo_cc. OK, works now. Thanks a lot. :) Marc --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Mon, 26 Jul 2004 13:37:01 -0700 (PDT), Jonathan Charnas <[EMAIL PROTECTED]> wrote: I'm not sure what's wrong, but if you have gentoo you can emerge the tarballs from portage and that will work. It's not a bugfix, but I assume you're not a developper (I'm probably wrong since you've tracked the errors in the code), and I further assume you only want to use the programs. So, if you don't use gentoo I'd be happy to download the tarballs and post them on my website for you temporarily. I know the portage tarballs compile cleanly, at least so far, and that includes entrance and entice. Another solution would be to go in #e and find out if someone has a more complete answer to your question. Cheers John Problem is solved. Thanks a lot for the offer, though :) Marc --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On 27/07/04, at 03:26 +0300, Oded Arbel <[EMAIL PROTECTED]> wrote: >[...] > I'm trying to build RPMs from CVS for my system (Mandrake 10). actually - > I'm writing a script that will allow to build E17 CVS and install it as RPMs > directly. the resulting RPMs will of course be useless for anyone not using > Mandrake 10, but the source RPMs generated will be useful to build the > specific CVS snapshot on other systems - much more so then checking out of > CVS would ever be. [snip] Interested in some nice and reliable spec files? I have made spec files of the following for FC1: # eet # edb # imlib2 # embryo # evas # ecore # edje # epeg # epsilon # estyle (deprecated!) # etox # esmart # ewl # iconbar # engage # entice # entrance # examine # elicit # emotion and they do work! They can be used for Mandrake too. Does Mandrake use xfree86 or xorg btw? Email me if you're interested. :-) With kind regards, Didier. --- PhD student. Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: didierbe at sps dot nus dot edu dot sg Web: http://ssls.nus.edu.sg --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Mon, 26 Jul 2004 22:04:58 +0200 [EMAIL PROTECTED] babbled: (B (B> Hello all, (B> (B> I downloaded yesterday most EFL libraries and some applications from CVS. (B> The libraries compiled fine, but when I tried to compile Entice and (B> Entrance I got the following error: (B (Bfixed. snprintf changes broke embryo_cc. (B (B> ... (B> edje_cc: Wrote 1743 bytes ( 2Kb) for "images/42" image entry (B> "border-bevel.png" compress: [raw: 44.4%] [real: -39.8%] (B> edje_cc: Wrote 11695 bytes ( 11Kb) for "collections/0" collection (B> entry (B> edje_cc: Wrote 1284 bytes ( 1Kb) for "collections/1" collection (B> entry (B> edje_cc: Wrote 625 bytes ( 1Kb) for "collections/2" collection (B> entry (B> embryo_cc: embryo_cc_sc1.c:2227: funcdisplayname: Assertion `tagsym[1] != (B> ((void *)0)' failed. (B> 6 (B> edje_cc: Warning. Compiling script code not clean. (B> make[3]: *** [default.eet] Fehler 255 (B> make[3]: *** Warte auf noch nicht beendete Prozesse... (B> ... (B> (B> So, I tried this and that, and found, that I couldn't even compile the (B> example in the embryo/examples directory, i.e. (B> (B> embryo_cc -oexample.sma example.amx (B> (B> gave the same error as above. Not even the empty file compiles. Messing (B> around a bit with the embryo_cc sources I tracked down (a possible (B> manifestation of) the problem, which is the parsing of "default.inc". It (B> seems, in embryo_cc_sc1.c funcdisplayname() gets called from (B> operatoradjust() shortly before a "symbol already defined" error. If I got (B> it right, it happens while parsing (B> (B> native Float:operator*(Float:oper1, Float:oper2) = float_mul; (B> (B> in the hidden calls section in default.inc. So, after some more tries, (B> with everything from that line on commented out, it compiled the example, (B> but when making Entice for example I get now "tag mismatch" errors. Not (B> that I had hoped much that this obscure "workaround" would actually (B> work... However, I'm at a loss of what to do next. (B> (B> Anybody has any idea what could be wrong? (B> (B> Marc (B> (B> (B> --- (B> This SF.Net email is sponsored by BEA Weblogic Workshop (B> FREE Java Enterprise J2EE developer tools! (B> Get your free copy of BEA WebLogic Workshop 8.1 today. (B> ___ (B> enlightenment-users mailing list (B> [EMAIL PROTECTED] (B> https://lists.sourceforge.net/lists/listinfo/enlightenment-users (B> (B (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click (B___ (Benlightenment-users mailing list (B[EMAIL PROTECTED] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Tuesday 27 July 2004 02:38, Michael Jennings wrote: > On Monday, 26 July 2004, at 23:26:25 (+0200), > > Andreas Volz wrote: > > And if the the questioner has a RPM based distribution you could > > perhaps use gentoo's feature to create RPM's with ebuild. I wonder > > why nobody yet uses this feature from gentoo to create (unofficial) > > RPM packages from E17 CVS? > > Because the resulting packages would be completely useless. There's a > reason you can't necessarily use FC2 RPM's on a RH9 box and vice > versa. Gentoo, Debian, and any other system capable of producing > RPM's has the same problem. > > The spec files for all the EFL libs are clean and working. RPM's are > easy to build, no Gentoo required. I really appriciate the effort of supplying valid spec files in the CVS - its make life so much easier for distributions and other packagers. I wish that more projects will follow. I'm trying to build RPMs from CVS for my system (Mandrake 10). actually - I'm writing a script that will allow to build E17 CVS and install it as RPMs directly. the resulting RPMs will of course be useless for anyone not using Mandrake 10, but the source RPMs generated will be useful to build the specific CVS snapshot on other systems - much more so then checking out of CVS would ever be. Now - I'm having some problems with doing so, which makes me think your last decleration may not be so true (especially the "easy" part). specificly I'm currently stuck with these problems, and I do hope someone can comment on how I can resolve this issues: - edje: autogen.sh does not work. the autogen.sh script looks nothing like the scripts for the other libraries, and bash complains about all the curly braces in the checks in the front. I can't tell what the problem as I'm not familiar with this syntax - I don't even think its valid bash. The m4 directory is also missing. - imlib2 does not build - it fails finding any files for the imlib-loader_gif sub-package. - imlib2_loaders does not have a spec file - it has a spec.in file. is the spec file supposed to be generated by the configure scripts ? that's kind of useless as configure is supposed to be run from the spec file. - I failed to build etox, but I don't think its RPM specific. I'll investigate more and write about it later. Also, issues general to all the libraries: - In all the libraries, autogen.sh by deafult runs configure (while the comment above it implies that it is commented out, which is not the case). as the order of building RPMs (AFAIU) is - autogen, rpmbuild (which runs configure, make and make install), that step is redundant. I currently solve this by automaticly "fixing" the autogen.sh script in my build process. - All the spec files are missing BuildRequires tags that are needed to force a build order - other wise users can try to build packages out of order and fail. the BuildRequires tag is supposed to help users by letting them know what they need before spending a lot of times (sometimes a couple of hours) on a build that would fail. I haven't tried to compile all the libraries as I got stuck on imlib2 and edje which most other libs depend on. -- Oded ::.. X windows: Putting new limits on productivity. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
On Monday, 26 July 2004, at 23:26:25 (+0200), Andreas Volz wrote: > And if the the questioner has a RPM based distribution you could > perhaps use gentoo's feature to create RPM's with ebuild. I wonder > why nobody yet uses this feature from gentoo to create (unofficial) > RPM packages from E17 CVS? Because the resulting packages would be completely useless. There's a reason you can't necessarily use FC2 RPM's on a RH9 box and vice versa. Gentoo, Debian, and any other system capable of producing RPM's has the same problem. The spec files for all the EFL libs are clean and working. RPM's are easy to build, no Gentoo required. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- "But what better way to go out than in the cause of advancing scientific knowledge?" "Is this a multiple choice question? 'cause I have some ideas" -- Jim Ishida and Claudia Christian, Babylon Five --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
Am Mon, 26 Jul 2004 13:37:01 -0700 (PDT) schrieb Jonathan Charnas: > I'm not sure what's wrong, but if you have gentoo you can emerge the > tarballs from portage and that will work. It's not a bugfix, but I > assume you're not a developper (I'm probably wrong since you've > tracked the errors in the code), and I further assume you only want to > use the programs. So, if you don't use gentoo I'd be happy to download > the tarballs and post them on my website for you temporarily. I know > the portage tarballs compile cleanly, at least so far, and that > includes entrance and entice. > Another solution would be to go in #e and find out if someone has a > more complete answer to your question. And if the the questioner has a RPM based distribution you could perhaps use gentoo's feature to create RPM's with ebuild. I wonder why nobody yet uses this feature from gentoo to create (unofficial) RPM packages from E17 CVS? It's very easy to do, because Gentoo is well supported. regards Andreas --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] can't get embryo_cc to work
--- [EMAIL PROTECTED] wrote: > Hello all, > > I downloaded yesterday most EFL libraries and some applications from > CVS. > The libraries compiled fine, but when I tried to compile Entice and > Entrance I got the following error: > > ... > edje_cc: Wrote 1743 bytes ( 2Kb) for "images/42" image entry > "border-bevel.png" compress: [raw: 44.4%] [real: -39.8%] > edje_cc: Wrote 11695 bytes ( 11Kb) for "collections/0" collection > entry > edje_cc: Wrote 1284 bytes ( 1Kb) for "collections/1" collection > entry > edje_cc: Wrote 625 bytes ( 1Kb) for "collections/2" collection > entry > embryo_cc: embryo_cc_sc1.c:2227: funcdisplayname: Assertion `tagsym[1] > != > ((void *)0)' failed. > 6 > edje_cc: Warning. Compiling script code not clean. > make[3]: *** [default.eet] Fehler 255 > make[3]: *** Warte auf noch nicht beendete Prozesse... > ... > > So, I tried this and that, and found, that I couldn't even compile the > example in the embryo/examples directory, i.e. > > embryo_cc -oexample.sma example.amx > > gave the same error as above. Not even the empty file compiles. Messing > > around a bit with the embryo_cc sources I tracked down (a possible > manifestation of) the problem, which is the parsing of "default.inc". It > > seems, in embryo_cc_sc1.c funcdisplayname() gets called from > operatoradjust() shortly before a "symbol already defined" error. If I > got > it right, it happens while parsing > > native Float:operator*(Float:oper1, Float:oper2) = float_mul; > > in the hidden calls section in default.inc. So, after some more tries, > with everything from that line on commented out, it compiled the > example, > but when making Entice for example I get now "tag mismatch" errors. Not > > that I had hoped much that this obscure "workaround" would actually > work... However, I'm at a loss of what to do next. > > Anybody has any idea what could be wrong? > > Marc I'm not sure what's wrong, but if you have gentoo you can emerge the tarballs from portage and that will work. It's not a bugfix, but I assume you're not a developper (I'm probably wrong since you've tracked the errors in the code), and I further assume you only want to use the programs. So, if you don't use gentoo I'd be happy to download the tarballs and post them on my website for you temporarily. I know the portage tarballs compile cleanly, at least so far, and that includes entrance and entice. Another solution would be to go in #e and find out if someone has a more complete answer to your question. Cheers John > > > --- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_idG21&alloc_id040&op=click > ___ > enlightenment-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] can't get embryo_cc to work
Hello all, I downloaded yesterday most EFL libraries and some applications from CVS. The libraries compiled fine, but when I tried to compile Entice and Entrance I got the following error: ... edje_cc: Wrote 1743 bytes ( 2Kb) for "images/42" image entry "border-bevel.png" compress: [raw: 44.4%] [real: -39.8%] edje_cc: Wrote 11695 bytes ( 11Kb) for "collections/0" collection entry edje_cc: Wrote 1284 bytes ( 1Kb) for "collections/1" collection entry edje_cc: Wrote 625 bytes ( 1Kb) for "collections/2" collection entry embryo_cc: embryo_cc_sc1.c:2227: funcdisplayname: Assertion `tagsym[1] != ((void *)0)' failed. 6 edje_cc: Warning. Compiling script code not clean. make[3]: *** [default.eet] Fehler 255 make[3]: *** Warte auf noch nicht beendete Prozesse... ... So, I tried this and that, and found, that I couldn't even compile the example in the embryo/examples directory, i.e. embryo_cc -oexample.sma example.amx gave the same error as above. Not even the empty file compiles. Messing around a bit with the embryo_cc sources I tracked down (a possible manifestation of) the problem, which is the parsing of "default.inc". It seems, in embryo_cc_sc1.c funcdisplayname() gets called from operatoradjust() shortly before a "symbol already defined" error. If I got it right, it happens while parsing native Float:operator*(Float:oper1, Float:oper2) = float_mul; in the hidden calls section in default.inc. So, after some more tries, with everything from that line on commented out, it compiled the example, but when making Entice for example I get now "tag mismatch" errors. Not that I had hoped much that this obscure "workaround" would actually work... However, I'm at a loss of what to do next. Anybody has any idea what could be wrong? Marc --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
