Refine the bultin and elf build

[Xiang Xiao]

This patch fix two major issues:

1.Unify the entry point to the standard main for both builtin/elf type.

   To avoid the symbol duplication, Makefile auto pass -Dmain=xxx_main when compiling MAINSRC for builtin apps.

2.Unify APPNAME and PROGNAME into one to avoid the confusion.

3.Other minor change include:

   a.Change tristate to bool for library code

   b.Change bool to tristate for new application

   c.Remove the unnecessary NSH_BUILTIN_APPS dependence

   d.Clean up Makefile

Greg, please help test the change don't break the mainline board config.

Thanks

Xiang

[Gregory Nutt]

Hi, Xaio,

My flight leaves here in just a few minutes.  I will review an incorporated the change tonight in the hotel.  I won't be able to do any testing until I return on the 16th.

Greg

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/761892a0-fb36-4ab8-a5b3-975db367b45a%40googlegroups.com.

[Gregory Nutt]

> My flight leaves here in just a few minutes.  I will review an
> incorporated the change tonight in the hotel.  I won't be able to do
> any testing until I return on the 16th.

I did take a few minutes to review, commit, and push the changes.  A lot
changes here so something could be broken.  I will not be able to test
anything until I am back from travel.

I think one important component that is missing the in the module
support is a proper support to make it really easy to build standalone
NuttX programs.  It should be as easy as it is with GCC and Linux:  gcc
-o program cfiles.

I think you could do that with a wrapper around GCC.  I did that in the
past (19 years ago!) with the XFLAT binaries that had to wrap standard
GCC and several custom tools together.  You can see that wrapper here:
https://bitbucket.org/patacongo/xflat/src/master/xflat/tools/gcc-xflat.c

With such a wrapper, building programs for NuttX would be a piece of
cake.  Shared library support would be another good feature.

[Matias N.]

Hi,

maybe it would be useful to have some sort of "migration" section on some readme file between prior NuttX release and the following release which will include these changes. I'm concerned this may break third-party apps and having a list of changes that should be applied to conform to the new approaches would be quite helpful.

Best,

Matias

-- 

You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/77f606e9-635b-8cf6-7263-0a6eb97177f0%40gmail.com.

[Xiang Xiao]

Yes, this change affect how to write an application, we should highlight in the ReleaseNotes:

1.The entry point is always main, we don't xxx_main anymore

2.Set application name by PROGNAME, APPNAME isn't used anymore

Thanks

Xiang

To unsubscribe from this group and stop receiving emails from it, send an email to nu...@googlegroups.com.

[Xiang Xiao]

Two more patch ix the cygpath usage.

On Sunday, October 6, 2019 at 7:47:48 PM UTC+8, patacongo wrote:

Hi, Xaio,

My flight leaves here in just a few minutes.  I will review an incorporated the change tonight in the hotel.  I won't be able to do any testing until I return on the 16th.

Greg

On 10/6/2019 5:05 AM, Xiang Xiao wrote:

This patch fix two major issues:

1.Unify the entry point to the standard main for both builtin/elf type.

   To avoid the symbol duplication, Makefile auto pass -Dmain=xxx_main when compiling MAINSRC for builtin apps.

2.Unify APPNAME and PROGNAME into one to avoid the confusion.

3.Other minor change include:

   a.Change tristate to bool for library code

   b.Change bool to tristate for new application

   c.Remove the unnecessary NSH_BUILTIN_APPS dependence

   d.Clean up Makefile

Greg, please help test the change don't break the mainline board config.

Thanks

Xiang

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nu...@googlegroups.com.

[Dave Marples]

On 07/10/2019 07:40, Xiang Xiao wrote:

Yes, this change affect how to write an application, we should highlight in the ReleaseNotes:

1.The entry point is always main, we don't xxx_main anymore

2.Set application name by PROGNAME, APPNAME isn't used anymore

Thanks

Xiang

Hi Xiang,

I am not a fan of this change. The 'main' definition is changed on the command line with a define, which (a) means your source code no longer corresponds to what is built and (b) means we are overriding some long established practice about C entry points.

I full understand why you're doing it but it obfuscates what is going on in the code...(and it seem to currently be broken, but that can be fixed).

Regards

DAVE

[xiang xiao]

On Mon, Oct 7, 2019 at 6:06 PM Dave Marples <da...@marples.net> wrote:
>
>
> On 07/10/2019 07:40, Xiang Xiao wrote:
>
> Yes, this change affect how to write an application, we should highlight in the ReleaseNotes:
> 1.The entry point is always main, we don't xxx_main anymore
> 2.Set application name by PROGNAME, APPNAME isn't used anymore
>
> Thanks
> Xiang
>
> Hi Xiang,
>
> I am not a fan of this change. The 'main' definition is changed on the command line with a define, which (a) means your source code no longer corresponds to what is built and (b) means we are overriding some long established practice about C entry points.
>

But this practice isn't complaint with ANSI C standard, and many
people can't understand the below code when he work with NuttX first
time:
#if defined(BUILD_MODULE)
int main(int argc, FAR char *argv[])
#else
int xxx_main(int argc, char *argv[])
#endif
{
...
}
I think this change is good because the primary goal of NuttX is
POSIX/ANSI complaint.

> I full understand why you're doing it but it obfuscates what is going on in the code...(and it seem to currently be broken, but that can be fixed).
>

BTW, the old code still work as before without any modification, but
it's better to remove #if/#else/#endif since the condition preprocess
make the code too ugly.

> Regards
>
> DAVE

>
>
> --
> You received this message because you are subscribed to the Google Groups "NuttX" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/8412af76-83a9-3a03-96b9-9160ccdf85dc%40marples.net.