Linux build.sh script
#31
np, dunno how your permissions got messed up. They should be preserved through subversion.
Reply
#32
Linux noob here...

I have followed the Wiki but got error since build.sh checks for packages needed, which are not installed. Yes, I missed the 1 line that tells you to check the Readme.linux Tongue

Maybe this is something that can be added to build.sh... check and download packages if missing?

Just a thought.

Al, thx for helping the community!
I'm not an expert but I play one at work.
Reply
#33
The only reason I don't add the package requirements is because I want to keep the script distribution independent. It's a PITA to detect distro and would be even more of a pain to maintain package lists for them all. Everyone should know, or learn quickly, to ALWAYs read the README before they do anything with open source software.
Reply
#34
The only thing that's a little off for me is that build.sh doesn't give you the chance to perform the apt-get after it updates README.linux. So you have to wait till a compiler error to see if you're missing packages. I typically svn up first, check the readme, then run build.sh. This works for me, but it's not as elegant as it could be.

Could maybe just support the 3 supported ubuntu versions, and allow the user to set them as oppose to trying to detect them.

But then again, all these problems will be gone with the .deb package that's released. Smile

xgrep
return null;
Reply
#35
Good point. build.sh now checks for changes to README.linux, forces the user to read it if so, then prompts whether or not to continue.
Reply
#36
Now that "make install" is available, should it be used for SVN releases or should we stick with build.sh?
Reply
#37
I'd leave it up to the user. The whole autotools thing could be too complex for some users. Not to mention you may not want to kill a working build with an untested broken one.
Reply
#38
I'm perfectly happy with build.sh but make install is significantly easier to package for debian/ubuntu... would prefer further development focus on that, IMO.
Reply
#39
Well, in my opinion, the Build.sh is like an equivalent of "make install". For the packaging, "make" is used to compile and "make install DESTDIR=xxx" to install in a temporary dir in which we will use to split the package into subpackage by specifying the files/dirs to include in each of them.

With the build.sh we can do the same :
use make then build.sh DEST=xxx NOCOMPILE NOCLEAN NOUPDATE

But for sure, the standard way of doing is make , make install
Reply
#40
Once the install target is full featured, I'll likely move build.sh to use it. Until then both will be developed.
Reply
#41
hello,

Can you check this patch ? http://sourceforge.net/tracker/index.php...tid=581840
It completes the install target (to be able to use the --prefix option) .

Thank you
Reply
#42
Erm...I dunno what you diffed that to but nothing in the patch even touches build.sh. I'm planning a complete rewrite soon anyway which will add support for this so no biggie.
Reply
#43
It doesn't touch the build.sh script because it's not meant to. It is for the Makefile install target.
Currently, using the SVN code level, you can install xbmc doing a make install but it will always install under /usr/share/xbmc . But usually the make install command uses a PREFIX=<dir> param to specify the install location. So this patch allows this.
Morover, the install path /usr/share/xbmc is hardcoded currently . Thus installing on another location will fail ( at runtime ). So the patch also changes this.

This is documented in the README.linux file ( after applying the patch )

Best regards
Reply
#44
wattazoum Wrote:It doesn't touch the build.sh script because it's not meant to. It is for the Makefile install target.
Currently, using the SVN code level, you can install xbmc doing a make install but it will always install under /usr/share/xbmc . But usually the make install command uses a PREFIX=<dir> param to specify the install location. So this patch allows this.
Morover, the install path /usr/share/xbmc is hardcoded currently . Thus installing on another location will fail ( at runtime ). So the patch also changes this.

This is documented in the README.linux file ( after applying the patch )

Best regards

Hi, from what I remember when I talked to d4rk about this patch he said that it wasn't viable to be put in svn because you use the PlatformDefs.h which didn't fit the crossplattform thing (I'm sorry if I'm vague, hope d4rk will spot this and clear it up Smile )
From what I remember he said it would be better to use config.h
He have quite much now but I'll poke and yell on him and hopefully he can conjure up a better explanation
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#45
I think I have a "proper" prefix patch. Testing ATM. I'll run it past d4rk and commit later tonight.
Reply

Logout Mark Read Team Forum Stats Members Help
Linux build.sh script1