MacPort version of Sigil

[curtw]

As a user, my big request would be to make this a Universal binary. I don't know if there's a specific reason that the original isn't Universal, but G5-and-earlier machines still make up a large portion of the Mac installed base. Universal and 10.4.11 compatibility would make it so *I* could use the program.

[Valloric]

Originally Posted by curtw

As a user, my big request would be to make this a Universal binary. I don't know if there's a specific reason that the original isn't Universal, but G5-and-earlier machines still make up a large portion of the Mac installed base. Universal and 10.4.11 compatibility would make it so *I* could use the program.

Now that Sigil is using the new build system, providing universal binaries should be fairly straightforward. You should see this in 0.1.2.

[curtw]

Originally Posted by Valloric

Now that Sigil is using the new build system, providing universal binaries should be fairly straightforward. You should see this in 0.1.2.

Hooray! thanks!

[krischik]

Originally Posted by pdurrant

In what way does it need more porting to the Mac? It needs some mac-specific fixes in the metadata, but the Applicaton itself looks very Mac-like. Native controls, proper menu bar, etc.

I thought everybody knows about MacPorts - Macports is a distribution for Mac. MacPorts already distributes QT - so a MacPorts distribution of Sigil would not need to bundle the QT libraries.

Martin

[krischik]

Originally Posted by curtw

As a user, my big request would be to make this a Universal binary. I don't know if there's a specific reason that the original isn't Universal, but G5-and-earlier machines still make up a large portion of the Mac installed base. Universal and 10.4.11 compatibility would make it so *I* could use the program.

MacPorts would sort that out as well as you would compile your own version for the CPU and Operating System you use.

Martin

[krischik]

Hi,

For MacPorts I need a short and long descriptions for tidylib and ZipArchive. That's because I need to make three different ports :-( .

Martin

[krischik]

Hi,

I am currently blocked - anybody with cmake experience who can help me?

Martin

[krischik]

Hi,

I did get around all the problems after all and Sigil is now available for MacPorts compatible systems.

In the end I needed three portfiles: libtidylib, libziparchive and Sigil.

Of course you only have to install the last one - MacPorts takes care of dependencies itself.

See the MacPorts Homepage for instructions on how to install MacPorts.

Martin

[Valloric]

Originally Posted by krischik

For MacPorts I need a short and long descriptions for tidylib and ZipArchive. That's because I need to make three different ports :-(

Please don't separate ZipArchive and tidyLib from Sigil. These are not the upstream versions and should not be present on user's systems. They are only statically linked in to the main Sigil application.

I cannot provide you with descriptions for these libraries since I didn't write them, I only modified them.

I must say I cannot support the development of a MacPorts version, or its build system. The only build system supported is the provided CMake version. Anything beyond that, and I'm sorry to say but you are on your own.

[krischik]

Originally Posted by Valloric

Please don't separate ZipArchive and tidyLib from Sigil. These are not the upstream versions and should not be present on user's systems. They are only statically linked in to the main Sigil application.

It would be nice to have clear instructions on how to do that - as the sigil make not find the other libs. If the Wiki is wrong - better delete it because once I found the Wiki i stopped looking for other instructions.

Originally Posted by Valloric

I must say I cannot support the development of a MacPorts version, or its build system. The only build system supported is the provided CMake version. Anything beyond that, and I'm sorry to say but you are on your own.

MacPorts does not use it's own build system - MacPorts calls the build system provided by the developer and in the case Sigil that is cmake.

Martin

[Valloric]

Originally Posted by krischik

In the end I needed three portfiles: libtidylib, libziparchive and Sigil.

This is a very, very bad idea. What happens when someone uses those two libraries for something other than Sigil? And it breaks because of the changes made to them?

These libraries were never meant to be available on a system level. There will come a time when this will cause great harm to certain users.

[Valloric]

Originally Posted by krischik

It would be nice to have clear instructions on how to do that - as the sigil make not find the other libs. If the Wiki is wrong - better delete it because once I found the Wiki i stopped looking for other instructions.

The wiki instruction are for Linux systems, and they are very clearly labeled as such. They are not general build instructions.

You can find those in the INSTALL.txt file in the repository.

[Valloric]

Originally Posted by krischik

MacPorts does not use it's own build system - MacPorts calls the build system provided by the developer and in the case Sigil that is cmake.

But I'm guessing you used the separate CMakeLists.txt files in each of the subdirectories, which you are not supposed to do.They are only meant to be loaded from the root dir CMakeLists.txt file that will descend to the subfolders and initiate specific builds.

You should learn CMake or follow the (correct) instructions more closely.

[krischik]

Hello,

Don't be upset about my mistakes. See them as a change to learn and improve documentation. I add a few so you know I am not all that serious.

Originally Posted by Valloric

This is a very, very bad idea. What happens when someone uses those two libraries for something other than Sigil? And it breaks because of the changes made to them?

Fine, I guess I have to remove them again .

Originally Posted by Valloric

You can find those in the INSTALL.txt file in the repository.

which INSTALL.txt ?

/Volumes/Work/macports/editors/sigil/work/Sigil_code_0.1.1  Darwin  martin@macpro  Mo Aug 10 16:44:11  standart  0 
>gfind . -iname INSTALL.txt
/Volumes/Work/macports/editors/sigil/work/Sigil_code_0.1.1  Darwin  martin@macpro  Mo Aug 10 16:44:33  standart  0 
>

Note that as a maintainer I only use the official release .

Originally Posted by Valloric

But I'm guessing you used the separate CMakeLists.txt files in each of the subdirectories, which you are not supposed to do.They are only meant to be loaded from the root dir CMakeLists.txt file that will descend to the subfolders and initiate specific builds.

Ahh, I see you mean that one :

/Volumes/Work/macports/editors/sigil/work/Sigil_code_0.1.1  Darwin  martin@macpro  Mo Aug 10 16:49:47  standart  0 
>ls -la
insgesamt 48
drwxr-xr-x 7 root admin   238  6. Aug 02:56 .
drwxr-xr-x 5 root admin   170 10. Aug 16:42 ..
-rw-r--r-- 1 root admin   773  5. Aug 02:18 .hgignore
-rw-r--r-- 1 root admin   619  5. Aug 02:18 CMakeLists.txt
-rw-r--r-- 1 root admin 35821  5. Aug 02:18 COPYING.txt
-rw-r--r-- 1 root admin  1070  6. Aug 02:54 ChangeLog.txt
drwxr-xr-x 5 root admin   170  6. Aug 02:56 src
/Volumes/Work/macports/editors/sigil/work/Sigil_code_0.1.1  Darwin  martin@macpro  Mo Aug 10 16:49:54  standart  0 
>

I have to say .txt is a great extension for a build file. You easily spot when close to COPYING.txt and ChangeLog.txt. . One would never think it is just another piece of documentation .

Now, again please don't be upset - I now it's your fault. The cmake guys should have known better then use .txt for a build script.

So I messed it up and I have to do it again .

Martin

[Valloric]

Originally Posted by krischik

I have to say .txt is a great extension for a build file. You easily spot when close to COPYING.txt and ChangeLog.txt. . One would never think it is just another piece of documentation .

Now, again please don't be upset - I now it's your fault. The cmake guys should have known better then use .txt for a build script.

Your second paragraph answers your first one: CMakeLists.txt is the name mandated by the CMake build tool. It's not something I can change.

Then again, having "CMake" as part of the name should make anyone at least curious enough to open it if they're using the CMake build system.