Build Under Linux

[JimShorts]

@dynmosaic wrote:

For build under windows, the same Makefile won’t work, since there is no sudo -E command.

Yeah, I called the build steps dir1, dir2, dir3, etc. just to avoid the problem you discovered. I had thought of using d_pcre (for example) but thought it was too much typing.

If you’re interested in it building under windows also, better to just add some intelligence in the makefile itself, and use a single makefile.

Just have some conditional code like this in the Makefile:

ifeq ($(shell uname), Linux)

SUDO_CMD=sudo -E

else

SUDO_CMD=sudo

endif



all:

@echo sudo command is $(SUDO_CMD)

[stickman]

@puddles wrote:

@dynmosaic wrote:

For build under windows, the same Makefile won’t work, since there is no sudo -E command.

Yeah, I called the build steps dir1, dir2, dir3, etc. just to avoid the problem you discovered. I had thought of using d_pcre (for example) but thought it was too much typing.

If you’re interested in it building under windows also, better to just add some intelligence in the makefile itself, and use a single makefile.

Just have some conditional code like this in the Makefile:

ifeq ($(shell uname), Linux)

SUDO_CMD=sudo -E

else

SUDO_CMD=sudo

endif



all:

@echo sudo command is $(SUDO_CMD)

Thanks puddles. A cross platform Makefile would be the best. I will test this.

Update:

On my Win7 installed with Cygwin, my uname is MINGW32_NT-6.1, but since I am only building under Windows and Linux, so an else would suffice, but if this Makefile is going to be made cross platform, maybe some other platform name should be included.

ifeq ($(shell uname), Linux)

SUDO_CMD=sudo -E

else

SUDO_CMD=

endif



all:

@echo sudo command is $(SUDO_CMD)

I have included the new Makefile, tested working under both Win7 and Ubuntu 10.10. One more advantage, I no longer need to start a MingW windows, since my dos command line was setup with the correct path to my Cygwin installation. I think it’s because the change I made to your COMMAND3 with the addition of the –build for libmpg123. Anyway, here is my final Makefile.

ifeq ($(shell uname), Linux)

SUDO_CMD=sudo -E

else

SUDO_CMD=

endif

COMMAND1 = (make && $(SUDO_CMD) make install)

COMMAND2 = (CC=$(DEVKITPPC)/bin/powerpc-eabi-gcc CXX=$(DEVKITPPC)/bin/powerpc-eabi-g++ ./configure --host=powerpc-eabi --build=powerpc-eabi-gnu --prefix="${DEVKITPRO}/portlibs/ppc" --libdir="${DEVKITPRO}/portlibs/ppc/lib" --disable-shared && 

make && $(SUDO_CMD) make install)

COMMAND3 = (CC=$(DEVKITPPC)/bin/powerpc-eabi-gcc ./configure --host=powerpc-eabi --build=powerpc-eabi-gnu --prefix="${DEVKITPRO}/portlibs/ppc" --libdir="${DEVKITPRO}/portlibs/ppc/lib" --enable-shared=no --enable-static=yes --with-cpu=ppc_nofpu --with-optimization=3 && 

cd src/libmpg123 && make && $(SUDO_CMD) make install)



all: dir1 dir2 dir3 dir4 dir5 dir6

dir1:

cd libntfs && $(COMMAND1)

dir2:

cd fribidi && $(COMMAND2)

dir3:

cd libexif && $(COMMAND2)

dir4:

cd libiconv && $(COMMAND2)

dir5:

cd pcre && $(COMMAND2)

dir6:

cd libmpg123 && $(COMMAND3)

I have also included the Makefile.gz for completeness.

[stickman]

puddles,

One more Q for you. Right now, when I go to libs, do a make, it will start to build for every library, does not matter whether there is any change or not. Is there a way to build only when there is a change? I guess one has to put in the right dependency. So what’s the best way of achieving this?

[JimShorts]

@dynmosaic wrote:

puddles,

One more Q for you. Right now, when I go to libs, do a make, it will start to build for every library, does not matter whether there is any change or not. Is there a way to build only when there is a change? I guess one has to put in the right dependency. So what’s the best way of achieving this?

Once the build completes there is some library that was built, buried down in the tree. This is what gets installed. Just determine a file that has to get built and use that to conditionally do the build.

For example:
dir1:
if [ ! -f libntfs/lib/libntfs.a ] ; then
cd libntfs && $(COMMAND1) ;
fi

Another thing I’d like is a target to “make clean”, but there doesn’t seem to be one. The whole thing seemed to be kind of a hack just to get the required libraries to be present.

If one were to do it right…

1)I’d put all the intelligence inside each subdirectory in libs, so each would have its own Makefile instead of the top one.
2) The top one would just have a SUBDIRS definition, and would just use an iteration mechanism to go into each subdir and make a target
3) All Makefiles would support the targets all, install and clean. You can do make clean multiple times without it erroring out (that is, all “rm” commands include the “-f” flag so they don’t fail even if the file to delete isn’t there.
4) Doing a “make all” on the toplevel would just do “make all” inside each subdirectory. Same for make install and make clean.
4) The make install step must be done by the user manually. On windows it’s “sudo make install”. On linux it’d be “sudo -E make install”. Note the -E is just to preserve the environment variables, which are needed to know where the devkitPPC tree is.

But that all would take some time to accomplish. And the real goal was tinkering with wiiMC in the first place…

ETA: Actually having the Makefiles be in each subtree can’t really work, as the Makefile itself has to be generated by using the right configure command. We had a hack I came up with where if you had a file “makefile” next to “Makefile”, the make utility itself will pick the “makefile” first. Then that file can invoke Makefile with “make -f Makefile” commands. But this won’t go over well if the OS is case insensitive.

[stickman]

@puddles wrote:

Once the build completes there is some library that was built, buried down in the tree. This is what gets installed. Just determine a file that has to get built and use that to conditionally do the build.

For example:
dir1:
if [ ! -f libntfs/lib/libntfs.a ] ; then
cd libntfs && $(COMMAND1) ;
fi

Thanks puddles for your suggestions. Sorry for the delay in replying. One of my harddisk drive got corrupted, I am having a hard time trying to recover the data from. It includes many games and videos that I have extracted from my game and dvd collections. I did not have all of them backed up, it would be an ordeal to go through the extraction again, esp the movies, some of them I copied from some friends or relative’s dvds. So I was hoping I can recover the hd. The cause, probably by WiiXplorer’s ftp server. I was using it to copy some file from my PC to the External HD connected to Wii, then suddenly the HD contents got corrupted. 🙁

However, this may not be the desired solution. As we are not just interested in the existence of libntfs.a, but the dependency of the change of any of source files in the libntfs directory, any change at all, this includes all the .h and .c files.

Maybe a make depend inside the Makefile, and a Make config? Somehow, do a make depend, if there is any new change in the .h or .c files, then do a make config? Is this possible? Something like the following?

SOURCES: source/*.h source/*.c
dep: $(SOURCES)
makedepend -fdepend -Y -I../include $(SOURCES)
config:
./configure ….

[JimShorts]

@dynmosaic wrote:

However, this may not be the desired solution. As we are not just interested in the existence of libntfs.a, but the dependency of the change of any of source files in the libntfs directory, any change at all, this includes all the .h and .c files.

I had thought all those libs were really just from some other source, included with WiiMC for convenience. And if you wanted to tinker with those libraries from within the WiiMC tree, couldn’t you just go inside and do normal development? Edit-make-make install-repeat.

At most I’d think you’d want to just upgrade those libraries from their original source upon occasion. But who knows if it’s an issue even. Upgrading just because there is a new version doesn’t always make sense. New features that WiiMC doesn’t even make use of wouldn’t add any value.

I don’t know, it seems to me the focus ought to be on WiiMC, not these irritating but unfortunately necessary support libraries…

[rodries]

You’re quite right, these are just the support libraries and are included in libs/ for convenience. For some there has been slight modifications made to get them to compile properly for PowerPC.

Most of the time there’s no noticeable benefit updating them.

The most important support library, which you will likely see a benefit to keeping up to date, is libogc.

[stickman]

@Tantric wrote:

You’re quite right, these are just the support libraries and are included in libs/ for convenience. For some there has been slight modifications made to get them to compile properly for PowerPC.

Most of the time there’s no noticeable benefit updating them.

The most important support library, which you will likely see a benefit to keeping up to date, is libogc.

I understand now, thanks for your clarification. I was blindly using them without recompiling them for a while under my window built, until recently the addition of libmpg123, as well as small change in libntfs. But as you said, those changes are of cosmetic nature, not worth our effort to keep track of. So for libs, it’s most likely build once, use many times scenario.

In terms of libogc, I did notice, many useful loaders, such as usbloader gx, cfgloader, wiiflow, as well as wiixplorer all uses it, but when I built, I need to use their own libogc version, not the one for wiimc. I created separate versions for them, and symbolic them at different build times. I wish all of them share the same libogc version. It would be so much easier.

Puddles, thanks for all your help, I learned a lot from you.

[Author]

Posts