Re: [E-devel] mac os x

2012-11-14 Thread Joerg Sonnenberger 
On Wed, Nov 14, 2012 at 03:25:35PM +0900, Carsten Haitzler wrote:
 On Tue, 13 Nov 2012 21:43:45 -0800 Dave Ray ap...@jonive.com said:
 
 wtf? somehting ADDED underscores in front of the symbols.. that is so wrong...
 the src as it reads in svn atm anyway doent have these and i dont see how a
 macro could do this as it'd need to replace each whole token not just _e and
 _E... something odd with the compiler/linker here.

Some platforms automatically prefix all external systems with _. a.out did this
on UNIX, but ELF no longer does. Not sure about OSX.

That said, you might be running into the default flat namespace on OSX,
which is more strict than ELF.

Joerg

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] mac os x

2012-11-13 Thread Dave Ray 
Hi,
Vincent Torri suggested I post here..
I'm getting the following when building /trunk/e/ on OSX. 

$ make
…
Making all in modules
 CC clock/e_mod_main.lo
clock/e_mod_main.c:811: warning: '_clock_fd_update' defined but not used
 CC clock/e_mod_config.lo
 CCLD   clock/module.la
Undefined symbols for architecture x86_64:
 _E_EVENT_BORDER_FULLSCREEN, referenced from:
 __clock_popup_new in e_mod_main.o
 _E_EVENT_DESK_AFTER_SHOW, referenced from:
 __clock_popup_new in e_mod_main.o
 _E_EVENT_SYS_RESUME, referenced from:
 _e_modapi_init in e_mod_main.o
 _e_action_add, referenced from:
 _e_modapi_init in e_mod_main.o
 _e_action_del, referenced from:
 _e_modapi_shutdown in e_mod_main.o
 _e_action_predef_name_del, referenced from:
 _e_modapi_shutdown in e_mod_main.o
 _e_action_predef_name_set, referenced from:
 _e_modapi_init in e_mod_main.o
 _e_config_descriptor_new, referenced from:
 _e_modapi_init in e_mod_main.o
 _e_config_dialog_find, referenced from:
 _e_int_config_clock_module in e_mod_config.o
 _e_config_dialog_new, referenced from:
 _e_int_config_clock_module in e_mod_config.o
 _e_config_domain_load, referenced from:
 _e_modapi_init in e_mod_main.o
 _e_config_domain_save, referenced from:
 _e_modapi_save in e_mod_main.o
 _e_config_save_queue, referenced from:
 __conf_item_get in e_mod_main.o
 __basic_apply_data in e_mod_config.o
 _e_container_current_get, referenced from:
 __clock_menu_cb_cfg in e_mod_main.o
 _e_gadcon_canvas_zone_geometry_get, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 _e_gadcon_client_aspect_set, referenced from:
 __eval_instance_size in e_mod_main.o
 _e_gadcon_client_min_size_set, referenced from:
 __eval_instance_size in e_mod_main.o
 _e_gadcon_client_new, referenced from:
 __gc_init in e_mod_main.o
 _e_gadcon_client_util_menu_items_append, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 _e_gadcon_popup_content_set, referenced from:
 __clock_popup_new in e_mod_main.o
 _e_gadcon_popup_new, referenced from:
 __clock_popup_new in e_mod_main.o
 _e_gadcon_popup_show, referenced from:
 __clock_popup_new in e_mod_main.o
 _e_gadcon_provider_register, referenced from:
 _e_modapi_init in e_mod_main.o
 _e_gadcon_provider_unregister, referenced from:
 _e_modapi_shutdown in e_mod_main.o
 _e_manager_current_get, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 __clock_menu_cb_cfg in e_mod_main.o
 _e_menu_activate_mouse, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 _e_menu_item_callback_set, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 _e_menu_item_label_set, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 _e_menu_item_new, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 _e_menu_new, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 _e_module_dir_get, referenced from:
 __gc_icon in e_mod_main.o
 _e_int_config_clock_module in e_mod_config.o
 _e_object_del, referenced from:
 _e_modapi_shutdown in e_mod_main.o
 __gc_shutdown in e_mod_main.o
 __clock_popup_fullscreen_change in e_mod_main.o
 __clock_cb_mouse_down in e_mod_main.o
 __clock_settings_cb in e_mod_main.o
 __clock_popup_desk_change in e_mod_main.o
 __clock_menu_cb_cfg in e_mod_main.o
 ...
 _e_shelf_desk_visible, referenced from:
 __clock_popup_desk_change in e_mod_main.o
 _e_theme_edje_object_set, referenced from:
 __gc_init in e_mod_main.o
 _e_int_clock_instances_redo in e_mod_main.o
 __clock_popup_new in e_mod_main.o
 _e_util_menu_item_theme_icon_set, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 _e_util_zone_current_get, referenced from:
 __clock_cb_mouse_down in e_mod_main.o
 _e_widget_button_add, referenced from:
 __clock_popup_new in e_mod_main.o
 _e_widget_check_add, referenced from:
 __basic_create_widgets in e_mod_config.o
 _e_widget_frametable_add, referenced from:
 __basic_create_widgets in e_mod_config.o
 _e_widget_frametable_object_append, referenced from:
 __basic_create_widgets in e_mod_config.o
 _e_widget_image_add_from_object, referenced from:
 __clock_popup_new in e_mod_main.o
 _e_widget_label_add, referenced from:
 __basic_create_widgets in e_mod_config.o
 _e_widget_radio_add, referenced from:
 __basic_create_widgets in e_mod_config.o
 _e_widget_radio_group_new, referenced from:
 __basic_create_widgets in e_mod_config.o
 _e_widget_table_add, referenced from:
 __clock_popup_new in e_mod_main.o
 __basic_create_widgets in e_mod_config.o
 _e_widget_table_object_align_append, referenced from:
 __clock_popup_new in e_mod_main.o
 _e_widget_table_object_append, referenced from:
 __basic_create_widgets in e_mod_config.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[4]: *** [clock/module.la] Error 1


Thanks,
Dave

Re: [E-devel] mac os x

2012-11-13 Thread The Rasterman 
On Tue, 13 Nov 2012 21:43:45 -0800 Dave Ray ap...@jonive.com said:

wtf? somehting ADDED underscores in front of the symbols.. that is so wrong...
the src as it reads in svn atm anyway doent have these and i dont see how a
macro could do this as it'd need to replace each whole token not just _e and
_E... something odd with the compiler/linker here.

 Hi,
 Vincent Torri suggested I post here..
 I'm getting the following when building /trunk/e/ on OSX. 
 
 $ make
 …
 Making all in modules
  CC clock/e_mod_main.lo
 clock/e_mod_main.c:811: warning: '_clock_fd_update' defined but not used
  CC clock/e_mod_config.lo
  CCLD   clock/module.la
 Undefined symbols for architecture x86_64:
  _E_EVENT_BORDER_FULLSCREEN, referenced from:
  __clock_popup_new in e_mod_main.o
  _E_EVENT_DESK_AFTER_SHOW, referenced from:
  __clock_popup_new in e_mod_main.o
  _E_EVENT_SYS_RESUME, referenced from:
  _e_modapi_init in e_mod_main.o
  _e_action_add, referenced from:
  _e_modapi_init in e_mod_main.o
  _e_action_del, referenced from:
  _e_modapi_shutdown in e_mod_main.o
  _e_action_predef_name_del, referenced from:
  _e_modapi_shutdown in e_mod_main.o
  _e_action_predef_name_set, referenced from:
  _e_modapi_init in e_mod_main.o
  _e_config_descriptor_new, referenced from:
  _e_modapi_init in e_mod_main.o
  _e_config_dialog_find, referenced from:
  _e_int_config_clock_module in e_mod_config.o
  _e_config_dialog_new, referenced from:
  _e_int_config_clock_module in e_mod_config.o
  _e_config_domain_load, referenced from:
  _e_modapi_init in e_mod_main.o
  _e_config_domain_save, referenced from:
  _e_modapi_save in e_mod_main.o
  _e_config_save_queue, referenced from:
  __conf_item_get in e_mod_main.o
  __basic_apply_data in e_mod_config.o
  _e_container_current_get, referenced from:
  __clock_menu_cb_cfg in e_mod_main.o
  _e_gadcon_canvas_zone_geometry_get, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  _e_gadcon_client_aspect_set, referenced from:
  __eval_instance_size in e_mod_main.o
  _e_gadcon_client_min_size_set, referenced from:
  __eval_instance_size in e_mod_main.o
  _e_gadcon_client_new, referenced from:
  __gc_init in e_mod_main.o
  _e_gadcon_client_util_menu_items_append, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  _e_gadcon_popup_content_set, referenced from:
  __clock_popup_new in e_mod_main.o
  _e_gadcon_popup_new, referenced from:
  __clock_popup_new in e_mod_main.o
  _e_gadcon_popup_show, referenced from:
  __clock_popup_new in e_mod_main.o
  _e_gadcon_provider_register, referenced from:
  _e_modapi_init in e_mod_main.o
  _e_gadcon_provider_unregister, referenced from:
  _e_modapi_shutdown in e_mod_main.o
  _e_manager_current_get, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  __clock_menu_cb_cfg in e_mod_main.o
  _e_menu_activate_mouse, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  _e_menu_item_callback_set, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  _e_menu_item_label_set, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  _e_menu_item_new, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  _e_menu_new, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  _e_module_dir_get, referenced from:
  __gc_icon in e_mod_main.o
  _e_int_config_clock_module in e_mod_config.o
  _e_object_del, referenced from:
  _e_modapi_shutdown in e_mod_main.o
  __gc_shutdown in e_mod_main.o
  __clock_popup_fullscreen_change in e_mod_main.o
  __clock_cb_mouse_down in e_mod_main.o
  __clock_settings_cb in e_mod_main.o
  __clock_popup_desk_change in e_mod_main.o
  __clock_menu_cb_cfg in e_mod_main.o
  ...
  _e_shelf_desk_visible, referenced from:
  __clock_popup_desk_change in e_mod_main.o
  _e_theme_edje_object_set, referenced from:
  __gc_init in e_mod_main.o
  _e_int_clock_instances_redo in e_mod_main.o
  __clock_popup_new in e_mod_main.o
  _e_util_menu_item_theme_icon_set, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  _e_util_zone_current_get, referenced from:
  __clock_cb_mouse_down in e_mod_main.o
  _e_widget_button_add, referenced from:
  __clock_popup_new in e_mod_main.o
  _e_widget_check_add, referenced from:
  __basic_create_widgets in e_mod_config.o
  _e_widget_frametable_add, referenced from:
  __basic_create_widgets in e_mod_config.o
  _e_widget_frametable_object_append, referenced from:
  __basic_create_widgets in e_mod_config.o
  _e_widget_image_add_from_object, referenced from:
  __clock_popup_new in e_mod_main.o
  _e_widget_label_add, referenced from:
  __basic_create_widgets in e_mod_config.o
  _e_widget_radio_add, referenced from:
  __basic_create_widgets in e_mod_config.o
  _e_widget_radio_group_new, referenced from:
  __basic_create_widgets in e_mod_config.o
  _e_widget_table_add, referenced

Re: [E-devel] Mac OS X and library version

2011-03-18 Thread The Rasterman 
On Thu, 17 Mar 2011 10:56:27 -0300 Iván Briano (Sachiel) sachi...@gmail.com
said:

 2011/3/17 Mike Blumenkrantz m...@zentific.com:
  On Thu, 17 Mar 2011 07:28:44 +0100
  s...@tango.flipp.net wrote:
 
  Hi,
 
  Got a complaint from a Mac OS X user that building from trunk fails. The
  reason is the v_mic number:
 
  ld: malformed version number: 2.999
 
  After checking I found the reason:
 
  -current_version number
        Specifies the current version number of the library. The current
  version of the library can
        be obtained programmatically by the user of the library so it can
  determine exactly which
        version of the library it is using.  The format of number is X[.Y
  [.Z]] where X must be a
        positive non-zero number less than or equal to 65535, and .Y and .Z
  are optional and if
        present must be non-negative numbers less than or equal to 255.  If
  the version number is
        not specified, it has a value of 0.  This option is also called
  -dylib_current_version for
        compatibility.
 
  So on OS X v_mic can't be larger than 255. Should we make this default for
  all platforms, or just for darwin?
 
  S.
 
  I think just setting it to 99 on all platforms would be sufficient, it's
  unlikely that we'll ever get that high?
 
 
 Most of the times you are way higher than that.

we canty change version as all the .999 versions now installed from trunk will
be newer than the .99 that is now newer. so i guess mac-osx is now unsupported
until we release 1.0.1 bugfix updates or 1.1 you cant use trunk without
modifying the version installed.

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac OS X and library version

2011-03-18 Thread Vincent Torri 



On Fri, 18 Mar 2011, Carsten Haitzler (The Rasterman) wrote:


On Thu, 17 Mar 2011 10:56:27 -0300 Iván Briano (Sachiel) sachi...@gmail.com
said:


2011/3/17 Mike Blumenkrantz m...@zentific.com:

On Thu, 17 Mar 2011 07:28:44 +0100
s...@tango.flipp.net wrote:


Hi,

Got a complaint from a Mac OS X user that building from trunk fails. The
reason is the v_mic number:

ld: malformed version number: 2.999

After checking I found the reason:

-current_version number
      Specifies the current version number of the library. The current
version of the library can
      be obtained programmatically by the user of the library so it can
determine exactly which
      version of the library it is using.  The format of number is X[.Y
[.Z]] where X must be a
      positive non-zero number less than or equal to 65535, and .Y and .Z
are optional and if
      present must be non-negative numbers less than or equal to 255.  If
the version number is
      not specified, it has a value of 0.  This option is also called
-dylib_current_version for
      compatibility.

So on OS X v_mic can't be larger than 255. Should we make this default for
all platforms, or just for darwin?

S.


I think just setting it to 99 on all platforms would be sufficient, it's
unlikely that we'll ever get that high?



Most of the times you are way higher than that.


we canty change version as all the .999 versions now installed from trunk will
be newer than the .99 that is now newer. so i guess mac-osx is now unsupported
until we release 1.0.1 bugfix updates or 1.1 you cant use trunk without
modifying the version installed.


so we revert it, and set it to 99 after the next release ?

Vincent--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac OS X and library version

2011-03-18 Thread The Rasterman 
On Fri, 18 Mar 2011 07:53:53 +0100 (CET) Vincent Torri vto...@univ-evry.fr
said:

 
 
 On Fri, 18 Mar 2011, Carsten Haitzler (The Rasterman) wrote:
 
  On Thu, 17 Mar 2011 10:56:27 -0300 Iván Briano (Sachiel)
  sachi...@gmail.com said:
 
  2011/3/17 Mike Blumenkrantz m...@zentific.com:
  On Thu, 17 Mar 2011 07:28:44 +0100
  s...@tango.flipp.net wrote:
 
  Hi,
 
  Got a complaint from a Mac OS X user that building from trunk fails. The
  reason is the v_mic number:
 
  ld: malformed version number: 2.999
 
  After checking I found the reason:
 
  -current_version number
        Specifies the current version number of the library. The current
  version of the library can
        be obtained programmatically by the user of the library so it can
  determine exactly which
        version of the library it is using.  The format of number is X[.Y
  [.Z]] where X must be a
        positive non-zero number less than or equal to 65535, and .Y and .Z
  are optional and if
        present must be non-negative numbers less than or equal to 255.  If
  the version number is
        not specified, it has a value of 0.  This option is also called
  -dylib_current_version for
        compatibility.
 
  So on OS X v_mic can't be larger than 255. Should we make this default
  for all platforms, or just for darwin?
 
  S.
 
  I think just setting it to 99 on all platforms would be sufficient, it's
  unlikely that we'll ever get that high?
 
 
  Most of the times you are way higher than that.
 
  we canty change version as all the .999 versions now installed from trunk
  will be newer than the .99 that is now newer. so i guess mac-osx is now
  unsupported until we release 1.0.1 bugfix updates or 1.1 you cant use trunk
  without modifying the version installed.
 
 so we revert it, and set it to 99 after the next release ?

yes. revert. osx will just not get support from trunk until then. too bad they
have such limiting version number support. peolpe will have to patch their own
installs in the meantime.

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Mac OS X and library version

2011-03-17 Thread sd 
Hi,

Got a complaint from a Mac OS X user that building from trunk fails. The
reason is the v_mic number:

ld: malformed version number: 2.999

After checking I found the reason:

-current_version number
Specifies the current version number of the library. The current version
of the library can
be obtained programmatically by the user of the library so it can
determine exactly which
version of the library it is using.  The format of number is X[.Y[.Z]]
where X must be a
positive non-zero number less than or equal to 65535, and .Y and .Z are
optional and if
present must be non-negative numbers less than or equal to 255.  If the
version number is
not specified, it has a value of 0.  This option is also called
-dylib_current_version for
compatibility.

So on OS X v_mic can't be larger than 255. Should we make this default for
all platforms, or just for darwin?

S.



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac OS X and library version

2011-03-17 Thread Vincent Torri 


On Thu, 17 Mar 2011, s...@tango.flipp.net wrote:

 Hi,

 Got a complaint from a Mac OS X user that building from trunk fails. The
 reason is the v_mic number:

 ld: malformed version number: 2.999

 After checking I found the reason:

 -current_version number
   Specifies the current version number of the library. The current version
 of the library can
   be obtained programmatically by the user of the library so it can
 determine exactly which
   version of the library it is using.  The format of number is X[.Y[.Z]]
 where X must be a
   positive non-zero number less than or equal to 65535, and .Y and .Z are
 optional and if
   present must be non-negative numbers less than or equal to 255.  If the
 version number is
   not specified, it has a value of 0.  This option is also called
 -dylib_current_version for
   compatibility.

 So on OS X v_mic can't be larger than 255. Should we make this default for
 all platforms, or just for darwin?

isn't 99 sufficient instead of 999 ?

Vincent

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac OS X and library version

2011-03-17 Thread Mike Blumenkrantz 
On Thu, 17 Mar 2011 07:28:44 +0100
s...@tango.flipp.net wrote:

 Hi,
 
 Got a complaint from a Mac OS X user that building from trunk fails. The
 reason is the v_mic number:
 
 ld: malformed version number: 2.999
 
 After checking I found the reason:
 
 -current_version number
   Specifies the current version number of the library. The current
 version of the library can
   be obtained programmatically by the user of the library so it can
 determine exactly which
   version of the library it is using.  The format of number is X[.Y[.Z]]
 where X must be a
   positive non-zero number less than or equal to 65535, and .Y and .Z
 are optional and if
   present must be non-negative numbers less than or equal to 255.  If
 the version number is
   not specified, it has a value of 0.  This option is also called
 -dylib_current_version for
   compatibility.
 
 So on OS X v_mic can't be larger than 255. Should we make this default for
 all platforms, or just for darwin?
 
 S.
 
I think just setting it to 99 on all platforms would be sufficient, it's
unlikely that we'll ever get that high?

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac OS X and library version

2011-03-17 Thread Sachiel 
2011/3/17 Mike Blumenkrantz m...@zentific.com:
 On Thu, 17 Mar 2011 07:28:44 +0100
 s...@tango.flipp.net wrote:

 Hi,

 Got a complaint from a Mac OS X user that building from trunk fails. The
 reason is the v_mic number:

 ld: malformed version number: 2.999

 After checking I found the reason:

 -current_version number
       Specifies the current version number of the library. The current
 version of the library can
       be obtained programmatically by the user of the library so it can
 determine exactly which
       version of the library it is using.  The format of number is X[.Y[.Z]]
 where X must be a
       positive non-zero number less than or equal to 65535, and .Y and .Z
 are optional and if
       present must be non-negative numbers less than or equal to 255.  If
 the version number is
       not specified, it has a value of 0.  This option is also called
 -dylib_current_version for
       compatibility.

 So on OS X v_mic can't be larger than 255. Should we make this default for
 all platforms, or just for darwin?

 S.

 I think just setting it to 99 on all platforms would be sufficient, it's
 unlikely that we'll ever get that high?


Most of the times you are way higher than that.

 --
 Mike Blumenkrantz
 Zentific: NULL pointer dereferences now 50% off!

 --
 Colocation vs. Managed Hosting
 A question and answer guide to determining the best fit
 for your organization - today and in the future.
 http://p.sf.net/sfu/internap-sfd2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac OS X, ecore config

2005-09-19 Thread Thomas 
I checked out CVS last night and am compiling now, it seems ewl is still
using the PF_ prefix:

ewl_config.c: In function `ewl_config_config_read':
ewl_config.c:209: error: `PF_MODIFIED' undeclared (first use in this
function)
ewl_config.c:209: error: (Each undeclared identifier is reported only once
ewl_config.c:209: error: for each function it appears in.)
ewl_config.c:210: error: `PF_SYSTEM' undeclared (first use in this
...

I attach a patch against ewl_config.c which replaces all PF_* with
ECORE_CONFIG_FLAG_*.

Chris Ross wrote:
 
 There is a problem with Ecore Config on OS X.
 
 Within the enumerated type 'Ecore_Config_Flag':
 
 typedef enum Ecore_Config_Flag
 {
PF_NONE = 0,
PF_BOUNDS = 1,
PF_MODIFIED = 2,
PF_SYSTEM = 4,
PF_CMDLN = 8
 } Ecore_Config_Flag;
 
 The problem is PF_SYSTEM, which, under OSX, is defined in the
 network headers to have the same value as AF_SYSTEM. This obviously
 causes the whole sheer-bang to mis-compile.
 
 Can I make a request to change the prefix from PF_ to ECF_ or EF_
 (or indeed any other prefix that is EFL related).
 
 Regards,
 
 Chris
-- 
Thomas C R Spurden  (0xBB944725)

--- ewl_config.c.bu 2005-09-19 15:48:21.0 +
+++ ewl_config.c2005-09-19 15:51:14.0 +
@@ -206,8 +206,8 @@ static void ewl_config_config_read(void)
 
cc = ewl_config_int_get(/ewl/theme/color_classes/count);
prop = ecore_config_get(/ewl/theme/color_classes/count);
-   prop-flags = ~PF_MODIFIED;
-   prop-flags |= PF_SYSTEM;
+   prop-flags = ~ECORE_CONFIG_FLAG_MODIFIED;
+   prop-flags |= ECORE_CONFIG_FLAG_SYSTEM;
 
for (i = 0; i  cc; i++) {
char *name;
@@ -217,8 +217,8 @@ static void ewl_config_config_read(void)
/ewl/theme/color_classes/%d/name, i);
name = ewl_config_str_get(key);
prop = ecore_config_get(key);
-   prop-flags = ~PF_MODIFIED;
-   prop-flags |= PF_SYSTEM;
+   prop-flags = ~ECORE_CONFIG_FLAG_MODIFIED;
+   prop-flags |= ECORE_CONFIG_FLAG_SYSTEM;
 
if (name) {
int r, g, b, a;
@@ -229,85 +229,85 @@ static void ewl_config_config_read(void)

/ewl/theme/color_classes/%d/r, i);
r = ewl_config_int_get(key);
prop = ecore_config_get(key);
-   prop-flags = ~PF_MODIFIED;
-   prop-flags |= PF_SYSTEM;
+   prop-flags = ~ECORE_CONFIG_FLAG_MODIFIED;
+   prop-flags |= ECORE_CONFIG_FLAG_SYSTEM;
 
snprintf(key, PATH_MAX,

/ewl/theme/color_classes/%d/g, i);
g = ewl_config_int_get(key);
prop = ecore_config_get(key);
-   prop-flags = ~PF_MODIFIED;
-   prop-flags |= PF_SYSTEM;
+   prop-flags = ~ECORE_CONFIG_FLAG_MODIFIED;
+   prop-flags |= ECORE_CONFIG_FLAG_SYSTEM;
 
snprintf(key, PATH_MAX,

/ewl/theme/color_classes/%d/b, i);
b = ewl_config_int_get(key);
prop = ecore_config_get(key);
-   prop-flags = ~PF_MODIFIED;
-   prop-flags |= PF_SYSTEM;
+   prop-flags = ~ECORE_CONFIG_FLAG_MODIFIED;
+   prop-flags |= ECORE_CONFIG_FLAG_SYSTEM;
 
snprintf(key, PATH_MAX,

/ewl/theme/color_classes/%d/a, i);
a = ewl_config_int_get(key);
prop = ecore_config_get(key);
-   prop-flags = ~PF_MODIFIED;
-   prop-flags |= PF_SYSTEM;
+   prop-flags = ~ECORE_CONFIG_FLAG_MODIFIED;
+   prop-flags |= ECORE_CONFIG_FLAG_SYSTEM;
 
snprintf(key, PATH_MAX,

/ewl/theme/color_classes/%d/r2, i);
r2 = ewl_config_int_get(key);
prop = ecore_config_get(key);
-   prop-flags = ~PF_MODIFIED;
-   prop-flags |= PF_SYSTEM;
+   prop-flags = ~ECORE_CONFIG_FLAG_MODIFIED;
+   prop-flags |= ECORE_CONFIG_FLAG_SYSTEM;

[E-devel] Mac OS X, ecore config

2005-09-15 Thread Chris Ross 


There is a problem with Ecore Config on OS X.

Within the enumerated type 'Ecore_Config_Flag':

typedef enum Ecore_Config_Flag
{
   PF_NONE = 0,
   PF_BOUNDS = 1,
   PF_MODIFIED = 2,
   PF_SYSTEM = 4,
   PF_CMDLN = 8
} Ecore_Config_Flag;

The problem is PF_SYSTEM, which, under OSX, is defined in the
network headers to have the same value as AF_SYSTEM. This obviously
causes the whole sheer-bang to mis-compile.

Can I make a request to change the prefix from PF_ to ECF_ or EF_
(or indeed any other prefix that is EFL related).

Regards,

Chris


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac OS X, ecore config

2005-09-15 Thread Michael Jennings 
On Thursday, 15 September 2005, at 13:01:54 (+0100),
Chris Ross wrote:

BOWIS!

 Within the enumerated type 'Ecore_Config_Flag':
 
 typedef enum Ecore_Config_Flag
 {
PF_NONE = 0,
PF_BOUNDS = 1,
PF_MODIFIED = 2,
PF_SYSTEM = 4,
PF_CMDLN = 8
 } Ecore_Config_Flag;
 
 The problem is PF_SYSTEM, which, under OSX, is defined in the
 network headers to have the same value as AF_SYSTEM. This obviously
 causes the whole sheer-bang to mis-compile.
 
 Can I make a request to change the prefix from PF_ to ECF_ or EF_
 (or indeed any other prefix that is EFL related).

This was an oversight by the author.  PF_* flags are reserved for libc
Protocol Family constants.  (See man socket for more.)

Hopefully there aren't too many of these in use!  They'll need to be
changed

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  [EMAIL PROTECTED]
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 I am I am I said I'm not myself, I'm not dead, and I'm not for sale.
  So keep your bankroll lottery eat your salad day deathbed motor-
  cade. -- Stone Temple Pilots, Trippin' on a Hole in a Paper Heart


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Mac OS X, ecore config

2005-09-15 Thread The Rasterman 
On Thu, 15 Sep 2005 13:01:54 +0100 Chris Ross [EMAIL PROTECTED] babbled:

 
 There is a problem with Ecore Config on OS X.
 
 Within the enumerated type 'Ecore_Config_Flag':
 
  typedef enum Ecore_Config_Flag
  {
 PF_NONE = 0,
 PF_BOUNDS = 1,
 PF_MODIFIED = 2,
 PF_SYSTEM = 4,
 PF_CMDLN = 8
  } Ecore_Config_Flag;
 
 The problem is PF_SYSTEM, which, under OSX, is defined in the
 network headers to have the same value as AF_SYSTEM. This obviously
 causes the whole sheer-bang to mis-compile.
 
 Can I make a request to change the prefix from PF_ to ECF_ or EF_
 (or indeed any other prefix that is EFL related).

this definitely needs fixing. if we are conflicitngn with system libs because
of lax namespacing on our part...

 Regards,
 
 Chris
 
 
 ---
 SF.Net email is sponsored by:
 Tame your development challenges with Apache's Geronimo App Server. Download
 it for free - -and be entered to win a 42 plasma tv or your very own
 Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多  [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel