On Mon, 13 Feb 2017 09:57:52 -0200 Gustavo Sverzut Barbieri <[email protected]> said:
> On Fri, Feb 10, 2017 at 8:58 AM, Carsten Haitzler <[email protected]> > wrote: > > On Thu, 9 Feb 2017 09:37:55 -0200 Gustavo Sverzut Barbieri > > <[email protected]> said: > > > >> On Sat, Feb 4, 2017 at 1:25 AM, Carsten Haitzler <[email protected]> > >> wrote: > >> > On Fri, 3 Feb 2017 08:46:39 -0200 Gustavo Sverzut Barbieri > >> > <[email protected]> said: > >> > > >> >> On Fri, Feb 3, 2017 at 7:22 AM, Carsten Haitzler <[email protected]> > >> >> wrote: > >> >> > On Fri, 27 Jan 2017 10:54:17 -0200 Gustavo Sverzut Barbieri > >> >> > <[email protected]> said: > >> >> > > >> >> >> Hi all, > >> >> >> > >> >> >> While porting to cmake I'm trying to use its features to enhance > >> >> >> portability, two are: > >> >> >> > >> >> >> https://cmake.org/cmake/help/v3.0/prop_tgt/FRAMEWORK.html > >> >> >> https://cmake.org/cmake/help/v3.0/prop_tgt/PUBLIC_HEADER.html > >> >> > > >> >> > the above explains very little... :( > >> >> > >> >> I know :-D that's why I'm asking to change our layout and be simple so > >> >> we get the "working out of the box" case. > >> >> > >> >> > >> >> >> These will generate MacOS compliant bundles but there is one caveat: > >> >> >> when I install they end all in a flat hierarchy, thus things that > >> >> >> includes relative to subdirectories, as Efl.h or Ector.h will fail to > >> >> >> find the "subdir/file.h". > >> >> > > >> >> > what do you mean exactly? you can't have -Idir flags as part of mac > >> >> > frameworks? so -framework doesnt make the framework base dir an added > >> >> > -I search location? so > >> >> > > >> >> > #include "interfaces/efl_observer.eo.h" > >> >> > #include "interfaces/efl_observable.eo.h" > >> >> > > >> >> > won't look for those files relative to PREFIX/include/efl-1 ? i'm not > >> >> > sure what ie "expected" here from mac and how we diffeer and what has > >> >> > to change to "be compliant" ? > >> >> > >> >> same here, I really don't know. > >> >> > >> >> >> One option is to avoid the PUBLIC_HEADER and manually install files > >> >> >> to include directories, there I can specify the subdirectories as > >> >> >> needed. However I'm not sure if that would be enough to MacOS and > >> >> >> possibly other systems, where the PUBLIC_HEADER could be hinting > >> >> >> something else. > >> >> >> > >> >> >> Another option, which I prefer, is to change the master include to > >> >> >> remove the subdirectories, also changing the automake rules. That > >> >> >> would result in all headers to be installed to a single directory: > >> >> >> /usr/include/${lib}-${vmaj}/ > >> >> >> > >> >> >> Any objections to this change? > >> >> > >> >> my change is basically removing "subdir/file" from our installed > >> >> headers. We can keep the GIT hierarchy and use SET(INCLUDE_DIRS ...) > >> >> ourselves. > >> > > >> > can you give me an example. i'm not sure what you mean? > >> > >> src/lib/efl/Efl.h: > >> > >> -#include "interfaces/efl_types.eot.h" > >> +#include "efl_types.eot.h" > > > > so we canit have dir/filename in headers as it doesnt use these partial file > > paths as a search relative to the -Iincludedir we'd normally add with pc > > files? it somehow doesnt use the same mechanism? > > > >> and in src/Makefile_Efl.am: > >> > >> lib_efl_libefl_la_CPPFLAGS = ... -I$(top_srcdir)/src/lib/efl/interfaces > >> > >> > >> as well in pc/efl.pc.in: > >> > >> Cflags: -I${includedir}/efl-1 -I${includedir}/efl-1/interfaces > > > > so we HAVE to place subdirs in -I include searches? boo. :( > > that's the simplest way to solve the autoconf as is and add cmake without > hacks. > > another option is to change autoconf ti install all to > ${includedir}/libname-ver/, iow: no subdirs to installed... that's how > most of the efl works, except: efl/interfaces, eolian-cxx/grammar and > evas/canvas. i guess it doesn't matter too much... BUt be careful. windows. case insensitive filesystems. do we have headers that conflict when case is ignored? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
