[bakefile-devel] copying OS X binary resources & isfile question

[Stefan Csomor]

Hi,

I have two problems I'd like to solve with bakefile for wxMac:

in trunk for the docview sample I've added the .icns for the document types,
now I have added a copy-files section like this to docview.bkl

<using module="datafiles"/>

<copy-files id="resources" cond="PLATFORM_MACOSX=='1'">
<dependency-of>all</dependency-of>
<srcdir>$(SRCDIR)</srcdir>
<dstdir>$(BUILDDIR)/docview.app/Resources</dstdir>
<files>chart.icns doc.icns notepad.icns</files>
</copy-files>

this seems to work, but I'm not sure if it's the 'right way'

then docview needs a different info.plist, but I can't seem to find a proper
way to formulate the section in mac_bundles.bkl so that in case such a file
exists in the source dir, it will be used, I've tried several variants of

<set var="BUNDLE_PLIST">
<if cond="$(os.path.isfile(envvar('srcdir')+'/Info.plist.in'))">
$(SRCDIR)/Info.plist.in
</if>
<if cond="$(os.path.isfile(envvar('srcdir')+'/Info.plist.in') ==
False)">
$(TOP_SRCDIR)src/osx/carbon/Info.plist.in
</if>
</set>

but I'm apparently too stupid to see the obvious ....

Thanks for any pointers

Stefan

[Stefan Csomor]

Hi

Post by Stefan Csomor
<dstdir>$(BUILDDIR)/docview.app/Resources</dstdir>

sorry copied from a wrong version, should read

<dstdir>$(BUILDDIR)/docview.app/Contents/Resources</dstdir>

Best,

Stefan

[Stefan Csomor]

Hi

just as an addition, I found out that for a simple test bakefile a line like

<set var="BUNDLE_PLIST">
<if cond="$(os.path.isfile(SRCDIR+'/Info.plist.in'))">

...

seems to work, but in mac_bundles.bkl, I don't seem to be able to get at the
true value of SRCDIR ...

thanks,

Stefan

[Vaclav Slavik]

Hi,

[context: speaking about wxWidgets' bakefiles]

Post by Stefan Csomor
in trunk for the docview sample I've added the .icns for the document types,
now I have added a copy-files section like this to docview.bkl
<using module="datafiles"/>
<copy-files id="resources" cond="PLATFORM_MACOSX=='1'">
<dependency-of>all</dependency-of>
<srcdir>$(SRCDIR)</srcdir>
<dstdir>$(BUILDDIR)/docview.app/Resources</dstdir>
<files>chart.icns doc.icns notepad.icns</files>
</copy-files>
this seems to work, but I'm not sure if it's the 'right way'

If it works -- i.e., correctly creates the .../Resources directory even
with -jN for N>1, then I don't see any problem with it. If it doesn't
work in parallel build, the simplest fix would be to make it depend on
the bundle target (that creates the directory).

Post by Stefan Csomor
then docview needs a different info.plist, but I can't seem to find a proper
way to formulate the section in mac_bundles.bkl so that in case such a file
exists in the source dir, it will be used, I've tried several variants of
<set var="BUNDLE_PLIST">
<if cond="$(os.path.isfile(envvar('srcdir')+'/Info.plist.in'))">
$(SRCDIR)/Info.plist.in
</if>

Couldn't work. No only is 'srcdir' not environment variable (or for that
matter, defined in anything other than autoconf format), so envvar()
doesn't work with it, you're passing an expression that cannot be
evaluated until make-time to a Python function that is evaluated at
bake-time and knows nothing about Bakefile specifics.

The simplest thing to do here would be to override BUNDLE_PLIST in the
sample that needs to customize it (untested, from the top of my head):

Index: build/bakefiles/mac_bundles.bkl
===================================================================
--- build/bakefiles/mac_bundles.bkl (revision 54781)
+++ build/bakefiles/mac_bundles.bkl (working copy)
@@ -15,10 +15,10 @@
`echo $(DOLLAR)(srcdir) | sed -e 's,\.\./,,g' | sed -e 's,/,.,g'`
</set>

- <set var="BUNDLE_PLIST">
+ <set var="BUNDLE_PLIST" override="0">
$(TOP_SRCDIR)src/osx/carbon/Info.plist.in
</set>
- <set var="BUNDLE_ICONS">
+ <set var="BUNDLE_ICONS" override="0">
$(TOP_SRCDIR)src/osx/carbon/wxmac.icns
</set>

Index: samples/docview/docview.bkl
===================================================================
--- samples/docview/docview.bkl (revision 54781)
+++ samples/docview/docview.bkl (working copy)
@@ -1,6 +1,10 @@
<?xml version="1.0" ?>
<makefile>

+ <!-- do this before the first <include>! -->
+ <set var="BUNDLE_PLIST">$(SRCDIR)/whatever</set>
+ <set var="BUNDLE_ICONS">$(SRCDIR)/chart.icns $(SRCDIR)/doc.icns ...</set>
+
<include file="../../build/bakefiles/common_samples.bkl"/>

<exe id="docview" template="wx_sample" template_append="wx_append">

(notice that it deals with the icons in a simpler way too).

HTH,
Vaclav

[Stefan Csomor]

Hi Vaclav

thanks a lot for your help !

while it is building in background two additional questions

1. why does the following work in the hello.bkl

<set var="TEST_VARIABLE">
<if cond="$(os.path.isfile(SRCDIR+'/hello.c'))">
$(SRCDIR+'/hello')
</if>
<if cond="$(not os.path.isfile(SRCDIR+'/hello.c'))">
$(SRCDIR+'/bye')
</if>
</set>


it gives me a ./hello for TEST_VARIABLE, and if I let it look for hello.cx
it gives me a ./bye

but I'm unable to do the same from mac_bundles.bkl ?

2. another OS X problem, unrelated to the vars above :

Currently we still have the single file executable built and then a .app
bundle built beside, in the end we link from Contents/MacOS/$(id) from the
bundle back to the executable, but this gives some people problems, can we
just change the destination for the exe to be INSIDE Contents/MacOS from the
start ?

Thanks,

Stefan

[Vaclav Slavik]

Post by Stefan Csomor
1. why does the following work in the hello.bkl

It doesn't, not with the autoconf format.

Post by Stefan Csomor
Currently we still have the single file executable built and then a .app
bundle built beside, in the end we link from Contents/MacOS/$(id) from the
bundle back to the executable, but this gives some people problems,

A little bit of specificity wouldn't hurt here...

Post by Stefan Csomor
can we just change the destination for the exe to be INSIDE Contents/MacOS from the
start ?

Not easily and without additional problems, I think. You may want to try
setting <dirname> to something dynamically determined.


Vaclav

[Stefan Csomor]

Hi

Post by Vaclav Slavik

Post by Stefan Csomor
1. why does the following work in the hello.bkl

It doesn't, not with the autoconf format.

what exactely is not working ? I have the following findings:

bakefile -f gnu hello.bkl

with a hello.bkl that has a

<set var="TEST_VARIABLE">
<if cond="$(os.path.isfile(SRCDIR+'/hello.c'))">
$(SRCDIR+'/hello.c')
</if>
<if cond="$(not os.path.isfile(SRCDIR+'/hello.c'))">
$(SRCDIR+'/another_hello.c')
</if>
</set>

allows me eg to use this TEST_VARIABLE

in a

<sources>$(TEST_VARIABLE)</sources>

clause, I've tested both situatations, if I do a rename of hello.c to
another_hello.c and rebake the GNUmakefile is adapted accordingly

Post by Vaclav Slavik

Post by Stefan Csomor
Currently we still have the single file executable built and then a .app
bundle built beside, in the end we link from Contents/MacOS/$(id) from the
bundle back to the executable, but this gives some people problems,

A little bit of specificity wouldn't hurt here...

ok, I thought you were aware of it, so I didn't want to elaborate on
something known: currently eg for the minimal sample the app is built once
as a single file ./minimal , in the finder this is the file with the old wx
icon. (This is the file that doesn't receive input when double clicked,
that's what people complain about on the list). Then the bundle is built and
in the mac_bundles.bkl we have the lines :

<!-- make a hardlink to the binary: -->
ln -f $(ref("__targetdir",id))$(ref("__targetname",id))
$(BUNDLE)/MacOS/$(id)

so ./minimal.app/Contents/MacOS/minimal links to ./minimal and the
minimal.app in the finder shows the new icon, can be double-clicked and
works w/o a problem

and what I'd like to achieve is to have the executable being built in
minimal.app/Contents/MacOS from the start

Post by Vaclav Slavik

Post by Stefan Csomor
can we just change the destination for the exe to be INSIDE Contents/MacOS
from the
start ?

Not easily and without additional problems, I think. You may want to try
setting <dirname> to something dynamically determined.

ok I'll try that

Thanks,

Stefan

[Vaclav Slavik]

Hi,

Post by Stefan Csomor

Post by Vaclav Slavik
It doesn't, not with the autoconf format.

what exactely is not working ?

The isfile() test, it always fails.

Post by Stefan Csomor
bakefile -f gnu hello.bkl

The behaviour with the "gnu" format (where it indeed does happen to
work) is irrelevant to the above claim that it doesn't work with the
*autoconf* format. wx uses the latter, not the former, so even though
you can make this work with "gnu" and at least some MSW formats, it
won't help you with your wx problem.

Post by Stefan Csomor
ok, I thought you were aware of it, so I didn't want to elaborate on
something known: currently eg for the minimal sample the app is built once
as a single file ./minimal , in the finder this is the file with the old wx
icon. (This is the file that doesn't receive input when double clicked,
that's what people complain about on the list).

In other words, the only problem is that people are confused by Finder's
representation of the build directory, right?

Vaclav

[Stefan Csomor]

Hi Vaclav

Post by Vaclav Slavik

Post by Stefan Csomor
ok, I thought you were aware of it, so I didn't want to elaborate on
something known: currently eg for the minimal sample the app is built once
as a single file ./minimal , in the finder this is the file with the old wx
icon. (This is the file that doesn't receive input when double clicked,
that's what people complain about on the list).

In other words, the only problem is that people are confused by Finder's
representation of the build directory, right?

mostly, there are now two applications with the same name visible to the
user, one works, the other doesn't

more technically there are two other steps in the build process which aren't
needed since we are doing bundles :

- the setting of the custom icon with SetFile, setting the type of the
single file exe to APPL, done with the ...__mac_setfilecmd,
- the rezzing of .r resource files, done with the ...._mac_rezcmd

if we get rid of those two steps, the single file exe gets at least a
terminal screen icon, and is also reflected in the info dialog as being a
'unix executable', the risk of mistaking one for the other would already be
reduced, I'd think at least ;-)

Thanks,

Stefan

[Vaclav Slavik]

Hi,

Post by Stefan Csomor
more technically there are two other steps in the build process which
- the setting of the custom icon with SetFile, setting the type of the
single file exe to APPL, done with the ...__mac_setfilecmd,
- the rezzing of .r resource files, done with the ...._mac_rezcmd

So these two are completely useless when developing (modern apps) for OS
X? If they are, as I think is the case, then all of this could be
removed from Bakefile, right?

In the meantime, is the "SetFile -t APPL binary_filename" call (not
setting icon, not doing rez) harmful too? If it isn't, then simply
removing all uses of <mac-res> from wx's bakefiles should be enough.

Vaclav

[Stefan Csomor]

Hi Vaclav

Post by Vaclav Slavik

Post by Stefan Csomor
more technically there are two other steps in the build process which
- the setting of the custom icon with SetFile, setting the type of the
single file exe to APPL, done with the ...__mac_setfilecmd,
- the rezzing of .r resource files, done with the ...._mac_rezcmd

So these two are completely useless when developing (modern apps) for OS
X? If they are, as I think is the case, then all of this could be
removed from Bakefile, right?

for bundle based applications yes, but single-file-apps are still supported
on OSX, it's just for wx that we got rid of all dependencies on these older
style resources, so I don't know about whether there are other users of
bakefile on osx which are either still relying on older wx versions or have
integrated their own .r files, but these could just keep using 0.23 I guess
..

Post by Vaclav Slavik
In the meantime, is the "SetFile -t APPL binary_filename" call (not
setting icon, not doing rez) harmful too? If it isn't, then simply
removing all uses of <mac-res> from wx's bakefiles should be enough.

the problem of SetFile -t APPL is that then again the binary shows up with
the generic application icon (sheet with pencil, ruler etc) and in the
finder info window it claims being a 'classic application' (because the
'carb' resources are missing)...

Best,

Stefan

[Vaclav Slavik]

Post by Stefan Csomor
for bundle based applications yes, but single-file-apps are still supported
on OSX,

I know, what I meant was if anybody in their right mind would develop
such apps now. I think that any modern Mac software will target OS X
only and ship as bundles, but I'm not sure. If it's true, then it should
be safe to simply remove all the cruft for dealing with old-style Mac
resources.

Post by Stefan Csomor
the problem of SetFile -t APPL is that then again the binary shows up with
the generic application icon (sheet with pencil, ruler etc) and in the
finder info window it claims being a 'classic application' (because the
'carb' resources are missing)...

I see :(

Thanks,
Vaclav

[Stefan Csomor]

Hi

Post by Vaclav Slavik

Post by Stefan Csomor
for bundle based applications yes, but single-file-apps are still supported
on OSX,

I know, what I meant was if anybody in their right mind would develop
such apps now.
I think that any modern Mac software will target OS X
only and ship as bundles, but I'm not sure. If it's true, then it should
be safe to simply remove all the cruft for dealing with old-style Mac
resources.

either it may be a non-gui console based app, which wouldn't need any
resources anyway, or if it is a GUI app then it really should be using
resouces, the same goes for shared libraries / plug-ins, so I'd vote for
removing everything related.

As for mac_bundles.bkl I'd suggest adding a convenience

BUNDLE_RESOURCES

which would essentially just copy everything to $(BUNDLE)/Resources

because although BUNDLE_ICONS now just does the same, I'd like to revert
that to the previous version and maybe call it BUNDLE_ICON or BUNDLE_ICNS as
it is always one single file ?

that way it would be clear what the app's icon is and everything else would
just be BUNDLE_RESOURCES, so eg also my doc icons for docview

shall I do this ?

Thanks,

Stefan

[Vaclav Slavik]

Post by Stefan Csomor
either it may be a non-gui console based app, which wouldn't need any
resources anyway, or if it is a GUI app then it really should be using
resouces, the same goes for shared libraries / plug-ins, so I'd vote for
removing everything related.

Ok: http://www.bakefile.org/ticket/223

Post by Stefan Csomor
As for mac_bundles.bkl I'd suggest adding a convenience
BUNDLE_RESOURCES
which would essentially just copy everything to $(BUNDLE)/Resources
because although BUNDLE_ICONS now just does the same, I'd like to revert
that to the previous version and maybe call it BUNDLE_ICON or BUNDLE_ICNS as
it is always one single file ?
that way it would be clear what the app's icon is and everything else would
just be BUNDLE_RESOURCES, so eg also my doc icons for docview
shall I do this ?

Feel free, if it works for you -- this is just wx's helper, so anything
that helps is welcome.

thanks,
Vaclav