On 11/21/13, 7:23 AM, Jacob Carlborg wrote:
> On 2013-11-21 12:17, Andrew Edwards wrote:

> Have you seen this:

I have.

> https://github.com/D-Programming-Language/installer/pull/24
>
> Also we already have a script that creates an installer for Mac OS X:
>
> https://github.com/D-Programming-Language/installer/tree/master/osx

Noted.

> Better to use what we already have.
>

I've looked at this. But what we have assumes that there is already a zip file present, fetches the zip and from that generates the an installer. My understanding is that the intent is to build the installer directly form the source on guthub. If my understanding is correct, then it either requires me to get the source and build it myself or have the the auto tester do the building and subsequently generating the installer. As I understand it, the second option is the desired desired state.

If my understanding is incorrect. I would appreciate clarification.

On 2013-11-21 13:43, Andrew Edwards wrote:

> I have.

So, why don't you use that instead of creating a completely new script?

> I've looked at this. But what we have assumes that there is already a
> zip file present, fetches the zip and from that generates the an
> installer. My understanding is that the intent is to build the installer
> directly form the source on guthub. If my understanding is correct, then
> it either requires me to get the source and build it myself or have the
> the auto tester do the building and subsequently generating the
> installer. As I understand it, the second option is the desired desired
> state.
>
> If my understanding is incorrect. I would appreciate clarification.

Yes, it would be preferred if it was built from source. But the solution is not to start from scratch and create a completely new script. As I said, use what we already have. If that's not working as we want it to, then we change it to do that.

You're missing several things when building the installer.

BTW, if you're able to figure out how to build the Mac OS X installer on Linux Walter would appreciate it. I failed to do that.

-- 
/Jacob Carlborg

On Thursday, 21 November 2013 at 13:56:07 UTC, Jacob Carlborg wrote:
> BTW, if you're able to figure out how to build the Mac OS X installer on Linux Walter would appreciate it. I failed to do that.

this might help:
https://github.com/hogliux/bomutils

On 2013-11-21 18:18, Joshua Niehus wrote:
> On Thursday, 21 November 2013 at 13:56:07 UTC, Jacob Carlborg wrote:
>> BTW, if you're able to figure out how to build the Mac OS X installer
>> on Linux Walter would appreciate it. I failed to do that.
>
> this might help:
> https://github.com/hogliux/bomutils

Yeah, I tried that, it didn't work. It's not just the Bom file that is causing troubles. I tried to extract an installer and then created an archive of its content using "xar", that's the file type the "file" command returned. I could run the installer but it failed to complete the installation.

-- 
/Jacob Carlborg

On 11/21/13, 8:56 AM, Jacob Carlborg wrote:
> On 2013-11-21 13:43, Andrew Edwards wrote:
>
>> I have.
>
> So, why don't you use that instead of creating a completely new script?
>
>> I've looked at this. But what we have assumes that there is already a
>> zip file present, fetches the zip and from that generates the an
>> installer. My understanding is that the intent is to build the installer
>> directly form the source on guthub. If my understanding is correct, then
>> it either requires me to get the source and build it myself or have the
>> the auto tester do the building and subsequently generating the
>> installer. As I understand it, the second option is the desired desired
>> state.
>>
>> If my understanding is incorrect. I would appreciate clarification.
>
> Yes, it would be preferred if it was built from source. But the solution
> is not to start from scratch and create a completely new script. As I
> said, use what we already have. If that's not working as we want it to,
> then we change it to do that.

To be honest, I started with the existing script. I would have loved to simply download and execute it and everything worked but it did not. It required more than an standard install of MAC OS X and the command line tools. Since I didn't have the full version of XCode or the particular products prompted for, I chose the route that required less preparatory work by the potential user. I do understand the necessity to build upon what already exists and, trust me, that's what I wanted to do.

> You're missing several things when building the installer.

Would have been great if you pointed them out but I completely understand.

> BTW, if you're able to figure out how to build the Mac OS X installer on
> Linux Walter would appreciate it. I failed to do that.
>

Will give it a shot. Thanks.

-- 
Regards,
--------------------
http://www.akeron.co
auto getAddress() {
    string location = "@", period = ".";
    return ("info" ~ location ~ "afidem" ~ period ~ "org");
}

On Saturday, 23 November 2013 at 00:16:33 UTC, Andrew Edwards wrote:

> To be honest, I started with the existing script. I would have loved to simply download and execute it and everything worked but it did not. It required more than an standard install of MAC OS X and the command line tools. Since I didn't have the full version of XCode or the particular products prompted for, I chose the route that required less preparatory work by the potential user. I do understand the necessity to build upon what already exists and, trust me, that's what I wanted to do.

I would have asked what's needed to build the installer instead of starting from scratch. What you need from that script is PackageMaker. Apparently it has been deprecated but it's still useable. It can be download here: https://developer.apple.com/downloads. It's part of "Auxiliary tools for Xcode Late July 2012", it requires a free developer account. It's expected to be installed in /Applications

> Would have been great if you pointed them out but I completely understand.

I can do that in a new post. I just thought it would be easier to use the existing scripts.

--
/Jacob Carlborg

On Thursday, 21 November 2013 at 11:18:44 UTC, Andrew Edwards wrote:

> #!/usr/bin/env /bin/bash

Since this script will only be run on Mac OS X there's no point in using the "env" command. Just hardcode the path to Bash.

> ##
> # Author:: Andrew Edwards
> # Version:: Initial created: 2013
> # License:: Public Domain
>
> # Create directories to house generated ouput
> mkdir -p .work  && cd .work
>
> # Fetch source from github
> getdmd="git clone -q --progress -bv$(<~/VERSION) https://github.com/D-Programming-Language";
> $getdmd"/dmd.git";
> $getdmd"/druntime.git";
> $getdmd"/phobos.git";
> $getdmd"/tools.git";
>
> # Build DMD, making changes to dmd.conf as necessary
> cd dmd;
> make -f posix.mak install;
> cat ../install/bin/dmd.conf | sed "s/-L--export-dynamic //g" > ../install/bin/dmd.conf2
> cat ../install/bin/dmd.conf2 | sed "s/-L-lrt//g" > ../install/bin/dmd.conf
> rm  ../install/bin/dmd.conf2

Don't patch dmd.conf. Change the makefile to do the right thing from the beginning.

> # Build DRUNTIME
> make -C ../druntime -f posix.mak install DMD=../install/bin/dmd
>
> # Build PHOBOS
> make -C ../phobos -f posix.mak install DMD=../install/bin/dmd
>
> # Build TOOLS
> make -C ../tools -f posix.mak install DMD=../install/bin/dmd
>
> # Move tools to correct location
> mv ../tools/generated/osx/default/catdoc ../install/bin
> mv ../tools/generated/osx/default/changed ../install/bin
> mv ../tools/generated/osx/default/ddemangle ../install/bin
> mv ../tools/generated/osx/default/detab ../install/bin
> mv ../tools/generated/osx/default/dget ../install/bin
> mv ../tools/generated/osx/default/rdmd ../install/bin
> mv ../tools/generated/osx/default/tolf ../install/bin

Not all of these tools are currently shipped with DMD. Don't know if we want to include all of these. We should probably start a new post about it.

> # Generate zip file
> ditto ../install ~/.dmg/usr/share/dmd
> ditto -jc --keepParent ~/.dmg/usr/share/dmd ~/dmd.$(<~/VERSION).bz2
>
> # Place DMD in path
> mkdir -p ~/.dmg/etc/paths.d
> cat >~/.dmg/etc/paths.d/dmd <<'EOT'
> /usr/share/dmd/bin
> /usr/share/dmd/man/man1
> EOT
>
> # Generate installer
> mkdir -p dmd.$(<~/VERSION)
>
> cat >dmd.$(<~/VERSION)/uninstall.command <<'EOT'
> #!/usr/bin/env bash
>
> sudo -p "Please provide your password to uninstall DMD: " rm -rf /usr/share/dmd
> sudo -p "Please provide your password to uninstall DMD: " rm -f /etc/paths.d/dmd

Don't remove the whole directory like that. Explicitly remove all files the installer put there and then remove the directory if it's empty. The user could have placed some own files in that directory. It happened with the latest Windows installer resulting in some angry posts.

> echo "Uninstallation complete!\n"
> EOT
>
> chmod +x dmd.$(<~/VERSION)/uninstall.command
>
> pkgbuild --identifier org.dlang.pkg.app --root ~/.dmg dmd.$(<~/VERSION)/dmd.$(<~/VERSION).pkg
> hdiutil create -ov -srcfolder dmd.$(<~/VERSION) ~/dmd.$(<~/VERSION).dmg

You're not using the dmd2.pmdoc file or corresponding. That will result in missing readme, licenses and other information.

> cd ~ && rm -rf .dmg .work
> </end file>

--
/Jacob Carlborg