Ns-3 on Visual Studio - Revision history

Pdbarnes: /* Alternative Proposals */ comment

2018-05-11T21:57:52Z

Alternative Proposals: comment

← Older revision		Revision as of 21:57, 11 May 2018
Line 276:		Line 276:
	* Works transparently through macros, including the <code>ATTRIBUTE_</code> macros.		* Works transparently through macros, including the <code>ATTRIBUTE_</code> macros.
	**''This approach will work and the patch has been updated to use this approach with one exception. Autogenerating the file at build time wont work because that would cause every source file in the whole project to be recompiled every time any modification is made to any file because Visual Studio uses the file modification time to determine which files need to be compiled. Visual Studio doesn't provide an analog to ./waf configure to configure the project before build time.		**''This approach will work and the patch has been updated to use this approach with one exception. Autogenerating the file at build time wont work because that would cause every source file in the whole project to be recompiled every time any modification is made to any file because Visual Studio uses the file modification time to determine which files need to be compiled. Visual Studio doesn't provide an analog to ./waf configure to configure the project before build time.
			** The file build/ns3/ns3-modules.h only needs to be created when the list of modules changes, not every build. How to achieve this in VS is up to you. If we can't solve this, we're stuck, because the original proposal to create src/core/ns3dll.h has the same issues (as well as other show-stoppers IMO).

	=== Phase 4 – NS-3 Implementation Changes for Visual Studio ===		=== Phase 4 – NS-3 Implementation Changes for Visual Studio ===

Rammon at 23:29, 3 May 2018

2018-05-03T23:29:15Z

← Older revision		Revision as of 23:29, 3 May 2018
Line 112:		Line 112:
	(2) With GNU ld, using the --export-all linker flag		(2) With GNU ld, using the --export-all linker flag

	* ''This approach ~~was~~ not ~~evaluated for two reasons, first the goal of the project was to set up a~~ Visual Studio ~~development environment that did~~ not require any other tools or software beyond Visual Studio. Second, using an approach like this would eliminate developer control of what was exported. While this may not be an issue for core ns-3 modules, with a contributor model, contributor may not want to make all of the implementation visible or external.		* ''This approach will not work because gcc and Visual Studio do not use identical rules for name mangling of C++ objects. The --export-all output would be specfic to gcc and would not work for Visual Studio.
	** ''Exporting all symbols is the current behavior (with two possible exceptions, see below). What's wrong with keeping this as the default?'' [[User:Pdbarnes\|Pdbarnes]] ([[User talk:Pdbarnes\|talk]])
	** ''Is there room to modify the overall goals for ~~the project? For example, instead of "pure VS environment" we could set the lower bar~~ of ~~"can be built and developed from VS", which leaves room for hybrid solutions, such as continuing to use waf, or other non-VS build tools/steps~~. ~~In particular, this might enable us to do something like~~ --export-all and ~~leverage the list of exported headers already present in wscript to indicate what should be exported. This~~ would ~~provide the same granularity as presently available~~.~~'' [[User:Pdbarnes\|Pdbarnes]] ([[User talk:Pdbarnes\|talk]])~~

	==== Digression on Current Symbol Export ====		==== Digression on Current Symbol Export ====
Line 140:		Line 138:
	#* ''Any name can be used for the export / import symbol name. The names chosen and list in ns3dll.h were created by me to be short (since they have to be added to the source code) yet provide enough detail on what they represent.		#* ''Any name can be used for the export / import symbol name. The names chosen and list in ns3dll.h were created by me to be short (since they have to be added to the source code) yet provide enough detail on what they represent.
	# Why does the value of the symbol need to be dynamic?		# Why does the value of the symbol need to be dynamic?
			#* ''As noted in the alternative proposal what the symbol resolves to depends on if the header file is being included in the module where the implementation resides or if it is used by another module to reference the module where the implementation resides.
	#Why don't all headers include ns3dll.h?		#Why don't all headers include ns3dll.h?
	#* ''All headers need the declarations provided in ns3dll.h. If ns3dll.h is included by another header file that is included in the header file (either directly or indirectly), it has already been included and adding it to the header file is not necessary. NOTE: There is no reason that this header file could not be included in every other header file, the patches submitted for review only included this file where it was necessary to reduce the size of the changes.		#* ''All headers need the declarations provided in ns3dll.h. If ns3dll.h is included by another header file that is included in the header file (either directly or indirectly), it has already been included and adding it to the header file is not necessary. NOTE: There is no reason that this header file could not be included in every other header file, the patches submitted for review only included this file where it was necessary to reduce the size of the changes.
Line 276:		Line 275:
	* Works equally well with contrib modules, since <code>ns3-modules.h</code> is auto-generated at build time, when the modules are known.		* Works equally well with contrib modules, since <code>ns3-modules.h</code> is auto-generated at build time, when the modules are known.
	* Works transparently through macros, including the <code>ATTRIBUTE_</code> macros.		* Works transparently through macros, including the <code>ATTRIBUTE_</code> macros.
			**''This approach will work and the patch has been updated to use this approach with one exception. Autogenerating the file at build time wont work because that would cause every source file in the whole project to be recompiled every time any modification is made to any file because Visual Studio uses the file modification time to determine which files need to be compiled. Visual Studio doesn't provide an analog to ./waf configure to configure the project before build time.


	=== Phase 4 – NS-3 Implementation Changes for Visual Studio ===		=== Phase 4 – NS-3 Implementation Changes for Visual Studio ===

Pdbarnes: /* Alternative Proposals */ add missing include line

2018-05-01T16:20:37Z

Alternative Proposals: add missing include line

← Older revision		Revision as of 16:20, 1 May 2018
Line 201:		Line 201:

	/* Usage:		/* Usage:
	Start each header with (assuming this is the core module):		Start each header with this three line block, after the last header inclusion (assuming this is the core module):
			#include "ns3-modules.h"
	#define NS3_MODULE NS3_CORE_MODULE		#define NS3_MODULE NS3_CORE_MODULE
	#include "ns3/ns3-export.h"		#include "ns3/ns3-export.h"

Rammon at 03:33, 1 May 2018

2018-05-01T03:33:40Z

@@ Line 36: / Line 36: @@
 The changes in this phase are changes to the existing NS-3 source code files to add conditional code for the Visual Studio development environment.  These changes add code that is executed under the Windows configuration only.
-For example, the following code from CORE is an example of code changed for Windows to produce the same log output:
+For example, the following code is an example of a header file that is not used and does not exist on Windows systems:
   <nowiki>#ifndef _WIN32
-#define NS_LOG_APPEND_FUNC_PREFIX                               \
+#include <unistd.h>
 #endif</nowiki>
 The modifications in this phase affect a minority of the NS-3 source code files.
 === Phase 3 – Visual Studio Class Declaration Changes ===

Pdbarnes: /* Alternative Proposals */ New proposal

2018-04-30T21:40:48Z

Alternative Proposals: New proposal

@@ Line 188: / Line 188: @@
 * Scales to contrib modules
 * No need to extend the ATTRIBUTE_x macros
 === Phase 4 – NS-3 Implementation Changes for Visual Studio ===

Pdbarnes: /* Proposed Method */

2018-04-30T20:39:07Z

Proposed Method

← Older revision		Revision as of 20:39, 30 April 2018
Line 124:		Line 124:
	* Not clear what to do with contrib modules. Does bake have to know how to insert contrib modules in this core file?		* Not clear what to do with contrib modules. Does bake have to know how to insert contrib modules in this core file?
	* How do we prevent modified ns3dll.h files from being pushed accidentally?		* How do we prevent modified ns3dll.h files from being pushed accidentally?

			These questions need to be addressed.

	==== Alternative Solutions ====		==== Alternative Solutions ====

Pdbarnes: /* Alternative Proposal */ Remove unworkable suggestion; leave the criteria

2018-04-30T20:37:48Z

Alternative Proposal: Remove unworkable suggestion; leave the criteria

@@ Line 180: / Line 180: @@
 The modifications in this phase affect almost every header file in the ns-3 source code.
-==== Alternative Proposal ====
+==== Alternative Proposals ====
-This alternative has been proposed, but not implemented or tested.
+Desirable attributes of any solution are:
 * All (exported) headers would have a common format
 * No need to mention every module in a core file (ns3dll.h)

Pdbarnes: /* ATTRIBUTE_x Macro Modifications */ clarification

2018-04-30T20:34:29Z

ATTRIBUTE_x Macro Modifications: clarification

← Older revision		Revision as of 20:34, 30 April 2018
Line 167:		Line 167:

	==== ATTRIBUTE_x Macro Modifications ====		==== ATTRIBUTE_x Macro Modifications ====
	Another example is all of the ATTRIBUTE_HELPER_* macros have been extended. ~~All ATTRIBUTE_HELPER_~~* macros now have an additional parameter (same one as previous section) that defines the DLL the "implementation" is located in. The following is an example from the CORE module. Use of any of the ATTRIBUTE_HELPER_* macros within a base ns-3 module require the new macro with the additional parameter.		Another example is all of the<code>ATTRIBUTE_HELPER_</code> macros have been extended. The <code>ATTRIBUTE_</code> macros declare a three classes for each underlying type <code>X</code>: <code>XValue</code>, <code>XAccessor</code> and <code>XChecker</code>. These are impacted by the import/export tag discussed above. As a result, the tag for the module ''invoking'' the macro has to be passed through to the macro, so they now have an additional parameter (same one as previous section) that defines the DLL the "implementation" is located in. The following is an example from the CORE module. Use of any of the <code>ATTRIBUTE_HELPER_*</code> macros within a base ns-3 module require the new macro with the additional parameter.
	<nowiki>		<nowiki>
	ATTRIBUTE_CHECKER_DEFINE_LIB (Boolean, NS3CORELIB);		ATTRIBUTE_CHECKER_DEFINE_LIB (Boolean, NS3CORELIB);
	ATTRIBUTE_ACCESSOR_DEFINE_LIB (Boolean, NS3CORELIB);</nowiki>		ATTRIBUTE_ACCESSOR_DEFINE_LIB (Boolean, NS3CORELIB);</nowiki>

	Note: Use of the ATTRIBUTE_HELPER_* macros locally ~~with~~ a program continue to use the previous macro and parameter sequence. An example is the following code from attribute-test-suite.c		Note: Use of the <code>ATTRIBUTE_HELPER_*</code> macros locally within a program continue to use the previous macro and parameter sequence. An example is the following code from attribute-test-suite.c

	<nowiki>		<nowiki>

Pdbarnes: /* Alternative Solutions */ comment on goals

2018-04-30T20:25:17Z

Alternative Solutions: comment on goals

← Older revision		Revision as of 20:25, 30 April 2018
Line 137:		Line 137:
	* ''This approach was not evaluated for two reasons, first the goal of the project was to set up a Visual Studio development environment that did not require any other tools or software beyond Visual Studio. Second, using an approach like this would eliminate developer control of what was exported. While this may not be an issue for core ns-3 modules, with a contributor model, contributor may not want to make all of the implementation visible or external.		* ''This approach was not evaluated for two reasons, first the goal of the project was to set up a Visual Studio development environment that did not require any other tools or software beyond Visual Studio. Second, using an approach like this would eliminate developer control of what was exported. While this may not be an issue for core ns-3 modules, with a contributor model, contributor may not want to make all of the implementation visible or external.
	** ''Exporting all symbols is the current behavior (with two possible exceptions, see below). What's wrong with keeping this as the default?'' [[User:Pdbarnes\|Pdbarnes]] ([[User talk:Pdbarnes\|talk]])		** ''Exporting all symbols is the current behavior (with two possible exceptions, see below). What's wrong with keeping this as the default?'' [[User:Pdbarnes\|Pdbarnes]] ([[User talk:Pdbarnes\|talk]])
			** ''Is there room to modify the overall goals for the project? For example, instead of "pure VS environment" we could set the lower bar of "can be built and developed from VS", which leaves room for hybrid solutions, such as continuing to use waf, or other non-VS build tools/steps. In particular, this might enable us to do something like --export-all and leverage the list of exported headers already present in wscript to indicate what should be exported. This would provide the same granularity as presently available.'' [[User:Pdbarnes\|Pdbarnes]] ([[User talk:Pdbarnes\|talk]])

	==== Digression on Current Symbol Export ====		==== Digression on Current Symbol Export ====

Pdbarnes: /* Phase 3 – Visual Studio Class Declaration Changes */ refactor discussion

2018-04-17T18:20:25Z

Phase 3 – Visual Studio Class Declaration Changes: refactor discussion

Show changes