Notice to the maintainers of OSx and Linux Builds

[jcapco]

Hi guys,

I am assuming that joepal and hdusel are responsible for the Linux and MacOS nightly builds. I have created a bin directory in the repository that will keep track of the binary builds (shouldnt be large). So far, things are working for windows and I want to extend this for Linux and MacOS.

For Linux, I don't see any glew or sdl binaries in the nightly builds so I assume that linux has a self-update on these dependencies and all I need to add is the makehuman executable file in the ./bin/linux directory (repectively in 64bit and 32bit). So I am almost done with linux, just need to write a clean update script.

For MacOS.. I am just soo confused. The nightly build file structure does look creepy. It even has the source-code of sdl and glew in it, whats up with that? This is supposed to be a release-mode build and the dependent external libraries should be binaries rather than code.

Anyway, no matter.. could anyone just help me fill in the bin folder of makehuman for MacOS. It should suppose to have MINIMAL amount of binaries and files (including binaries of the dependent libraries if the OS do not do an automatic update on the dependencies). For example, you could always look at the ./bin/win directory and follow the same idea. And a similar update script like written in ./update.bat should be made for MacOS (which should be more complicated than for other system.. the way I see the file structure are created). Any help would be appreciated, if you arent a commiter you can just send me the file and instruction on how to place them in the system (Im just not too familiar with MacOS' file structure). All I need to do is add the binaries and whenever I execute update-osx.sh I should have an

Code: Select all

svn update

command executed and then I want the script to collect binaries from the ./bin/osx directory and place the newly executable and binaries in their respective places in the system (for windows its just the working directory of makehuman).

jcapco

[joepal]

Has this bug actually been fixed? http://code.google.com/p/makehuman/issu ... d=23&can=1 Otherwise moving the linux binary to a separate directory will cause MH to fail to load textures.

[jcapco]

thanks for referring me to the bug. Its easy to fix that problem. Ill get on it asap.

But on another note, we arent moving the executable directory somewhere else, we are just collecting them in the bin directory for versioning (for the repository only, on real releases bin shouldnt be there). With the update script we make a copy from the bin directory for the corresponding OS to the makehuman working/root directory.

[hdusel]

...
For MacOS.. I am just soo confused. The nightly build file structure does look creepy. It even has the source-code of sdl and glew in it, whats up with that?
This is supposed to be a release-mode build and the dependent external libraries should be binaries rather than code.

Hi jcapco,

Mixing headers and libs is not creepy because for the developer they actually belong to each other.

See since SDL, SDL_image and glew are 3rd party packages it makes sense so separate their headers from those of the project. So this is the reason why these 3rd party packages (or called frameworks (see below)) are carry the headers *and* the libs. Sure the headers are not needed for the final executable but they will be needed for the build process.

In order to give you an understanding what "frameworks" is and what the idea behind this is you might look at http://developer.apple.com/mac/library/ ... works.html. Please keep in mind: (OS-X) Frameworks are actually shipped by the developers of the corresponding package. In our case the guys around SDL and GLEW will create and ship the framework. And again - this framework contains headers because a framework is to build an app which uses this.

Anyway, no matter.. could anyone just help me fill in the bin folder of makehuman for MacOS. It should suppose to have MINIMAL amount of binaries and files (including binaries of the dependent libraries if the OS do not do an automatic update on the dependencies). For example, you could always look at the ./bin/win directory and follow the same idea. And a similar update script like written in ./update.bat should be made for MacOS (which should be more complicated than for other system.. the way I see the file structure are created). Any help would be appreciated, if you arent a commiter you can just send me the file and instruction on how to place them in the system (Im just not too familiar with MacOS' file structure). All I need to do is add the binaries and whenever I execute update-osx.sh I should have an

Code: Select all

svn update

command executed and then I want the script to collect binaries from the ./bin/osx directory and place the newly executable and binaries in their respective places in the system (for windows its just the working directory of makehuman).

jcapco

In my understanding the bins belongs to a dedicated build or flavor of makehuman.

So IMHO a folder called "bin" which stands alone and outside just to enrich a certain build doesn't make a big sense for me because these "bins" are actually should belong to a "build process".

So instead of this I'd suppose to create a directory called build and within this we create one called "win32", another one which is called "linux" and another one called "os-x" makes sense.

Each of these build directories contains each dependent bins which are needed to "build" the certain binary of makehuman for every OS.

BTW that was the reason why I created a folder called "os-x" which contains all the "additional" stuff to create makehuman for OS-X *only*.

So I expected that - besides of this - another directory called win32 and linux will be created in order to enrich these by each platform dependent binaries/header/resources/special images/licenses for contributions etc. which are not common for makehuman but are needed to create makehuman for each certain os.

I have another question: I have seen that you proposed "bin/" contains makehman as its executable either.

So do you expect that we commit this final build for very certain change in the sources/resources/ ?

I guess that this will not a good idea because this will bloat the svn repository in general and each svn update for every participant in special a lot - for every change of the code / resource...On the other if side every little change will cause to a new makehman.exe (or a whole update of the package). So every maintainer has to commit its updated version. How do you ensure that each makehuman.exe is consistent to the scripts/data?

I guess this should be the sense of the nightly build. Or what should be the policy to update makehuman.exe

So for these reasons I don't like the idea of a separated folder called bin/

What do you think?

Regards - Peter -

[jcapco]

In my understanding the bins belongs to a dedicated build or flavor of makehuman.

So IMHO a folder called "bin" which stands alone and outside just to enrich a certain build doesn't make a big sense for me because these "bins" are actually should belong to a "build process".

So instead of this I'd suppose to create a directory called build and within this we create one called "win32", another one which is called "linux" and another one called "os-x" makes sense.

Each of these build directories contains each dependent bins which are needed to "build" the certain binary of makehuman for every OS.

BTW that was the reason why I created a folder called "os-x" which contains all the "additional" stuff to create makehuman for OS-X *only*.

To me at least, the name is no big deal. If someone wants to call it "build" then so be it. (Btw, the developers discuss these stuffs in a common meeting).

But first let us clear a misunderstanding that one of us may have...

I have another question: I have seen that you proposed "bin/" contains makehman as its executable either.

So do you expect that we commit this final build for very certain change in the sources/resources/ ?

I guess that this will not a good idea because this will bloat the svn repository in general and each svn update for every participant in special a lot - for every change of the code / resource...On the other if side every little change will cause to a new makehman.exe (or a whole update of the package). So every maintainer has to commit its updated version. How do you ensure that each makehuman.exe is consistent to the scripts/data?

I guess this should be the sense of the nightly build. Or what should be the policy to update makehuman.exe

So for these reasons I don't like the idea of a separated folder called bin/

What do you think?

Regards - Peter -

The policy is: Developers update the bin folder not nightly build maintainers. For OSX there is a problem, as none of us developer build in OSX. So we need a support from a maintainer for that. But if the maintainer has no time for it, then its not a big deal either.

And regarding the svn being clogged/bloated: Majority of our developments are in the python codes (in the past year we probably made 4 or 5 significant changes in the C-builds, requiring new builds). Thus, at least for this particular project, if bin are updated ONLY when there is a change in the C-code (src folder) then there is nothing to worry about. I can predict the next reasonable build to be commited in the ./bin folder to be maybe in 3-6months from now. Its not a day to day update, unlike the python codes. In fact if nightly-build-maintainers want to maintain the ./bin folder, this is also no problem. One just needs a script that builds and copies to bin when a flag from

Code: Select all

svnlook changed  ./src

is turned on. Disregarding all that.. in windows the executable binary is 44kb, in linux its about maybe max 200kb (and Im guessing the build was not optimized). Is there really something to worry about?

In any case, I maintain the windows and linux binaries (I just extract it from the nightly build of joepal whenever there is a new change in ./src), because they consist of only one executable and 4 never-changing dll's for windows. The way I look at it, I get the feeling that the OSX builds are never meant to be portable. For instance, If you copy ./bin/win in the root folder and copy the entire makehuman in a usb stick and go somewhere, you can execute it in windows (in linux, the machine should have had python and other external binaries installed).

I havent used makehuman in OSX, but I can guess that surely the builds are not dependent on the *.py files.

[hdusel]

...
In any case, I maintain the windows and linux binaries (I just extract it from the nightly build of joepal whenever there is a new change in ./src), because they consist of only one executable and 4 never-changing dll's for windows. The way I look at it, I get the feeling that the OSX builds are never meant to be portable. For instance, If you copy ./bin/win in the root folder and copy the entire makehuman in a usb stick and go somewhere, you can execute it in windows (in linux, the machine should have had python and other external binaries installed).

Hi jcapco,

Now I think I understand what you mean by the term portable in general and the sense of the folder bin in special.

You mean portable in the meaning of copying the platform specific binaries together with the other data and python scripts in order to get a running package.

Yes in this terms you are right. The OS X Port of MH is not portable in this meaning, because an Mac OS X App is an so called "App Bundle" which means that the user gets one Package and sees just one "File" despite there is a bunch of folders (Resources, Executable etc.) in it. This was never a relevant issue for me.

Actually all the stuff you see as windows or linux user when you unpack an zip archive which contains such a .app folder. Those .app folder are marked with an special flag - the so called bundle flag - which is another cute OS X feature.

This flag tells the OS X Filemanager (aka finder) just to expose the .app-folder as an Icon and not show it as a regular folder. So when the user clicks on such a Icon then it will start the app and not open its folder what it actually is.

In addition the anatomy of such a App-Bundle has some rules. The Rules you see on every Mac OS X App Bundle...

BTW these Bundles are IMHO the big advantage of OS X, because in contrast to linux and Win the User will never see all the shared libs (in OS X the Frameworks) among the resources because these files will be hidden by the OS X Filemanager (aka Finder). Those Bundles will be created by the Development tool chain automatically and its affordable to create this by a simple script as your install.bat

But anyway - I think if the portability is a matter in this definition - portable by creating an app by copying stuff - only, then I'd suppose that we shouldn't waste our time and skip this issue for OS X and concentrate to further development of MH.

Do you agree?

The binaries (even those which has not changes) will be created every night as part of the nightly build on my build server. So every user has a change to gain access this package.

If you don't have anybody who creates the build for OS X then you will have a problem either. At latest - here you are right - when anybody changes things in one of the .c files... This problem remains if you don't have any maintainer for OS X. But this issue remains for any platform...

Best Regards,

- Peter -

[jcapco]

Agreed Thanks for the lively discussion. Ill soon put up a tutorial for people who don't know how to update using the script I provided in the root directory.