This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: EXEEXT settable in generated buildtree, via CDL ??


> If you look at the tail of the root makefile you
will 
> see something like:
> 
> $(PREFIX)/include/pkgconf/ecos.mak: makefile
>         @echo 'ECOS_GLOBAL_CFLAGS = -Wall
> -Wpointer-arith -Wstrict-prototypes -Winline -Wundef
> -Woverloaded-virtual -g -O2 -ffunction-sections
> -fdata-sections -fno-rtti -fno-exceptions
-fvtable-gc -finit-priority' > $@
>         @echo 'ECOS_GLOBAL_LDFLAGS = -g -nostdlib
> -Wl,--gc-sections -Wl,-static' >> $@
>         @echo 'ECOS_COMMAND_PREFIX =
> $(COMMAND_PREFIX)' >> $@

i have seen this earlier also, but i haven't seen
ecos.mak included by subdirectory makefiles in
buildtrees generated by ecosconfig versions 1.3.net or
2.0b1 (on win2K), though ecos.mak gets generated
during make. i cross-checked this fact with both the
versions before sending this mail.

subdirectory makefiles include 
"include $(REPOSITORY)/pkgconf/rules.mak"
and that file conditionally does "include $(wildcard
*.deps)".

so first rules.mak needs to include this ecos.mak of
buildtree --
include $(PREFIX)/include/pkgconf/ecos.mak

however ideal will be that generated buildtree
makefiles include ecos.mak, as it is also generated
transparent to user.

but if things go in ecos.mak and it gets included in
every makefile directly/indirectly then changing
extension in existing buildtree would be minor change
for those who know where and what change to make in
generated buildtree, under your suggestion.

however if you look at the beginning of the file, part
contents comes from global build options, this is what
i had tried many months back - having a new global
build option CYGBLD_EXEEXT / CYGBLD_GLOBAL_EXEEXT ,
but it didn't appear in generated tree (though it was
in .ecc file)

so looks like not all the CYGBLD_* names get through.
may be some cdl maintainer can shed more light on it.

if there were some way provided that by adding couple
of lines in one central place, one could allow for
more/newer CYGBLD_GLOBAL options, any Tom Dick Harry
could do that.

if it is useful options for community in general, then
i would spend some time, i will try sending a patch to
list. though simply editing the generated makefile is
also good enough for developers, who understand ecos.

logically speaking, EXEEXT fits more with variables
CC, AR, HOST, COMMAND_PREFIX than with *FLAGS that go
in ecos.mak .

even "@echo 'ECOS_COMMAND_PREFIX = $(COMMAND_PREFIX)'"
can be removed from going into ecos.mak, and
ECOS_COMMAND_PREFIX can be placed at the toplevel
along with others.

however a grep through a sample build tree (and also
in packages/pkgconf) does't show any usage of
ECOS_COMMAND_PREFIX. why it is there then?

if you look at it, it is only variable that goes into
ecos.mak and has nothing to do with how code will be
compiled/linked.

regards
sandeep



		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]